Consumer repos have no built-in way to keep generated *.lock.yml in sync (drift/freshness gap) #1663

Summary

Repos that consume ado-aw commit the generated .github/agents/*.lock.yml next to its source .md. There is currently no built-in, consumer-facing way to guarantee the committed lock stays in sync with (a) its source .md and (b) the pinned ado-aw compiler version. Every consumer repo ends up hand-rolling its own drift check and version-bump automation — which is duplicative and easy to get wrong.

Where this bites

Upgrading a consumer's pinned compiler (e.g. 0.36.0 -> 0.45.1) and editing an agent's frontmatter surfaced three failure modes:

• A version bump not followed by ado-aw compile leaves the lock's COMPILER_VERSION / release-download URLs pointing at the new version while the generated body is still the old one — an internally inconsistent pipeline.
• Editing the source .md without recompiling silently desyncs the running pipeline from what is in the repo.
• Every mitigation is per-repo boilerplate: a Renovate custom manager + postUpgradeTasks recompile (needs allowedPostUpgradeCommands, usually unavailable on a shared org Renovate instance), or a standalone ado-aw check PR pipeline (needs its own branch-policy registration). Each consumer has to replicate this.

Ask: resolve it universally in ado-aw

The building blocks already exist — the ado-aw check command, and ado-aw already recompiles its own fixtures on each release. Please expose this to consumers so no repo needs bespoke wiring. Options, roughly in preference order:

1. Self-check baked into the generated lock (or a shared template consumers extends). compile already knows the source + compiler version, so the generated pipeline could run ado-aw check on itself as an early fast-fail step — every compiled pipeline would be drift-protected for free, with no per-repo YAML.
2. Release-driven recompile PRs for consumers. Extend the existing on-release fixture recompile to open "recompile lock" PRs against onboarded consumer repos when a new version ships — centralizing bump + recompile instead of per-repo Renovate.
3. Agency dispatch guard. Since Agency is the central trigger for these pipelines, have it refuse to run (or warn) when a lock does not match its source at the pinned compiler.

Option 1 alone would remove the need for every consumer to add a custom ado-aw check gate.

Note

This is separate from the inline-suggestion rendering fixed in v0.38.0 (#1104, "render applyable PR suggestions correctly"). This issue is specifically about lock freshness / drift for consumer repos, not suggestion rendering.