`gh aw compile` should manage Dependabot ignore rules for compiler-emitted action refs

[ericsciple]

Problem

When a repo using gh-aw enables Dependabot for the github-actions ecosystem, Dependabot scans every .lock.yml for uses: entries and proposes version bumps. That includes refs the gh-aw compiler emits on the user's behalf, like github/gh-aw-actions/setup.

These compiler-emitted refs are version-aligned with the gh-aw compiler that produced the lock file. Bumping them independently desyncs the runtime helpers from the compiler, which can break workflows at runtime.

Concrete failure mode: Dependabot opens a PR bumping github/gh-aw-actions/setup@<sha-A> to @<sha-B>. The user merges. The next run uses setup at <sha-B> against runtime expectations baked in by an older gh-aw compiler, and behavior diverges from what the user's .md source describes.

The same applies to any other refs gh-aw bakes into the compiled artifact (other actions in gh-aw-actions/*, runtime scripts, internal helpers).

github-actions Dependabot has no per-file or glob exclusion; the only way to suppress these PRs is per-dependency ignore rules in dependabot.yml. Asking every gh-aw user to add and maintain that stanza by hand is a footgun.

Proposal

Have gh aw compile manage the ignore rules in .github/dependabot.yml automatically, the same way it manages .lock.yml.

Behavior:

1. No dependabot.yml: do nothing. Compiler does not create the file. Creating it would enable Dependabot on a repo that wasn't using it, which is a side effect users wouldn't expect from running a compiler.
2. dependabot.yml exists but has no github-actions entry: do nothing. Adding an entry would turn on a new ecosystem the user hadn't opted into.
3. dependabot.yml has a github-actions entry: inject or update the managed ignore: entries inside it, leaving everything else (other ecosystems, user-defined ignores, schedule, reviewers, groups, etc.) untouched.

The principle: the compiler only ever suppresses noise within what the user has already opted into. It never expands Dependabot's footprint.

Documentation should still cover the case where a user wants to enable Dependabot for github-actions on a gh-aw repo (provide the snippet), but creating or expanding the file is a user decision, not a compiler decision.

Wrap each compiler-managed entry with an inline comment so users can tell what's hands-off:

updates:
  - package-ecosystem: github-actions
    directory: /.github/workflows
    schedule:
      interval: weekly
    ignore:
      - dependency-name: "github/gh-aw-actions/**" # Managed by gh aw compile. Version-locked to the gh-aw compiler; do not bump.
      - dependency-name: "actions/checkout"   # user-defined, preserved

Rules:

• The compiler reconciles only entries whose dependency-name matches its set of managed patterns (e.g., github/gh-aw-actions/**). Everything else in the file is preserved verbatim.
• If a managed entry is missing on recompile, the compiler adds it. If a user removes one by hand, it comes back on next compile (which is the point).
• The list of managed patterns lives in the compiler, not in the user's repo. Adding a new compiler-emitted namespace in a future gh-aw release is a single source change; users pick it up on next compile.

Open questions

• Escape hatch: if a user genuinely wants Dependabot to bump gh-aw-actions/** (e.g., they pin gh-aw to a non-default version and want the helpers to follow), is there a way to opt out of the managed ignore? A frontmatter flag, a sentinel comment the compiler respects, or just "remove gh-aw and manage by hand"?
• YAML round-tripping in gh-aw: does the existing YAML library preserve comments and ordering well enough to edit dependabot.yml in place without churn? Worth a quick spike.