BUG: 'setup-cli' action referenced by mutable tag instead of commit SHA in maintenance workflow

[grahame-white]

Summary

The agentics-maintenance.yml workflow compiled by gh-aw v0.64.0 references github/gh-aw-actions/setup-cli using the mutable tag @v0.64.0 rather than a pinned full commit SHA. Every other action in this repo (and in copilot-setup-steps.yml) is pinned to a commit SHA for supply-chain integrity and reproducibility. This inconsistency weakens the security posture of the workflow.

What failed

• uses: github/gh-aw-actions/setup-cli@v0.64.0 — mutable tag, not a SHA pin.
• All other action references in the same repository use SHA-pinned references.

Why it failed

• The compiler's action pinning logic (via GetActionPin() and .github/aw/actions-lock.json) did not resolve and emit the commit SHA for setup-cli in the context of the maintenance workflow generation.

Root cause

• Gap in the action pinning/lock resolution logic in the compiler when generating maintenance workflow references to setup-cli.
• The correct SHA is known (51c65948c64ab6752536ead71fba1fc2c20ed0bc) and is used elsewhere; it simply wasn't applied here.

Supporting evidence / References

• PR Review Copilot observation 11
• Compiler pinning code: GetActionPin() and .github/aw/actions-lock.json
• Example of correct SHA pinning in copilot-setup-steps.yml in same repo

Proposed fix

• Ensure GetActionPin() (or equivalent) correctly resolves and emits the SHA for setup-cli in all compiler code paths, including maintenance workflow generation.
• The suggestion from review: uses: github/gh-aw-actions/setup-cli@51c65948c64ab6752536ead71fba1fc2c20ed0bc # v0.64.0
• Add a compiler test asserting that all emitted action references are SHA-pinned (no bare tags).

Implementation plan

1. Audit compiler workflow generators for any setup-cli or other action references that bypass the GetActionPin() / actions-lock.json resolution path.
2. Fix the identified code path to use the SHA from the lock.
3. Add a test asserting no mutable tag references in any compiled .lock.yml output.