Evaluate wrkflw as a local GitHub Actions runner

[gentamura]

Summary

Investigate whether we should adopt wrkflw instead of act for running GitHub Actions workflows locally.

Pros

• Built-in validator (wrkflw validate) can catch workflow schema issues before pushing.
• Offers both Docker/Podman execution and an emulation mode for environments where container runtime access is limited.
• Provides a TUI and CLI with job dependency visualization, parallel execution, and on-demand remote triggering.
• Native handling for composite, JavaScript, and local actions plus common actions like actions/checkout.

Cons

• Young project (first release March 2025) with low adoption; stability and long-term maintenance are unproven.
• Several GitHub features remain unsupported or partial (e.g., caching, artifacts, advanced expressions, Windows/macOS runners).
• Requires Rust toolchain (cargo) for installation; no prebuilt binaries yet.
• Documentation notes performance limits for large matrix builds and potential gaps in GitHub-specific environment simulations.

Questions

• Do we rely on any features that wrkflw lacks (caching, artifacts, service containers, etc.)?
• Are there security or IT policies that would prefer Docker vs Podman vs emulation?
• Would wrkflw's TUI materially improve contributor experience over our current act usage?

Next steps

• Pilot wrkflw on a subset of workflows and compare results/time against act.
• Document any blockers (missing features, bugs) and upstream them if we proceed.
• Decide whether to maintain both tools or fully replace act after evaluation.