Decide whether genesis should have its own auto-merge workflow now that CI exists

[genesis-dev-bot]

Split out of #37, which asked to decide this "in the same change". It isn't the same
change — auto-merge only makes sense once there's a real gate to merge behind, and
that gate (.github/workflows/ci.yml) is what #37 / #38 just added. Deciding it
separately means the decision can be made against a CI job that actually exists.

The gap

Genesis is the only repo in the family that can't self-advance past a PR. Every dev
system genesis seeds gets genesis-merge.yml; genesis itself does not. So every
framework fix — the turn-budget floor, the concurrency guard, the CI workflow itself —
needed a human hand on the button, and sat open until someone noticed.

What to weigh

• Risk profile differs. A dev repo auto-merging its own work is contained. Genesis
  auto-merging changes to templates/ propagates to every repo it seeds afterward.
  That asymmetry is the actual question, not the mechanics.
• workflows: write is now known to matter. The evolver's app token needed it to
  push ci.yml at all (the default GITHUB_TOKEN refused). Any auto-merge path
  touching workflow files hits the same permission.
• CI is the natural gate. ci.yml is free, fast, secret-free, and runs on every
  PR — a usable required check. Making it a branch-protection requirement may be worth
  doing on its own, independently of whether auto-merge lands.
• Middle option: require CI green + human approval, and let the merge itself be
  automatic. Keeps a human judging the change without keeping them on the button.

Suggested outcome

Either seed genesis-merge.yml into genesis gated on CI, or close this with a written
rationale for why genesis stays human-merged. Both are fine; the status quo is that
nobody decided.