Emit GitHub-native workflow lockfiles (.github/workflows/actions.lock) at compile time #70264

GitHub's workflow dependency lockfiles (gh actions-lock, .github/workflows/actions.lock) are now in public preview. gh-aw generated workflows would benefit from this support, but their dependencies are compiler-owned, so consumers cannot onboard them cleanly.

Problem
gh-aw already records resolved dependencies in the gh-aw-manifest header and .github/aw/actions-lock.json (SHA-only, one entry per action). But the new GitHub-native lockfile is a separate artifact, and for generated workflows consumers face a three-way conflict:

Dependabot cannot maintain the pins. Action versions in generated .lock.yml files are chosen by the pinned gh-aw toolchain and baked in at compile time; Dependabot PRs touching them drift from compiler output and must be reverted. We currently work around this with a weekly gh aw upgrade automation ("auto-update vehicle") that recompiles and opens a single PR.
Native lockfiles add a second source of truth. Running gh actions-lock against a generated workflow records toolchain-chosen SHAs in actions.lock; the next gh aw compile with a different toolchain invalidates it. Gate recipes that verify byte-exact compiler output will fight the lockfile.
Transitive dependencies of composite actions are not in the manifest. The gh-aw-manifest actions array lists direct uses: pins only; the native lockfile's transitive coverage would close that gap, but only if it is generated alongside the workflow.
Proposed solution
Have gh aw compile emit (or refresh) .github/workflows/actions.lock entries for generated workflows, using the same resolution the manifest uses:

entries for all direct and transitive action dependencies, plus reusable workflow deps and container digests where applicable
stable, deterministic output so gh aw compile is idempotent with respect to the lockfile (byte-stable for the same toolchain)
gh aw add --force / gh aw upgrade keep the lockfile in sync in the same commit that moves the toolchain
This would let GitHub's Require lockfile policy cover generated workflows, make Dependabot's "regenerates the matching lockfile entry in the same PR" behavior compose with toolchain bumps, and let us retire the bespoke auto-update wrapper in favor of plain gh aw upgrade.

Workaround today
Consumers keep hand-written workflows on actions.lock and leave generated workflows to the toolchain + recompile gates, duplicating pinning logic in CI. Happy to test a preview implementation against our repos (frumfinance org: 3 gh-aw consumer repos with generated workflows + compiled lock verification gates).