Add ci-passed release admission to decouple merges from deploy time

[mberman84]

Why

The release-admission hold is the biggest throughput limiter in DeployBot: after a batch merges, no newer batch is admitted until the cumulative exact-main release is fully verified live (CI → deploy → health checks). The deployment step is usually the largest chunk of that wait, so merges end up serialized behind deploy time even though the only correctness-critical gate is "don't stack new merges on red CI."

This adds an opt-in policy so teams can reopen admission as soon as exact-main CI is green, letting deploy and health checks finish in the background while the next batch merges.

What changed

• New pipeline.release_admission policy with two values:
  • verified (default) — unchanged behavior: wait for the cumulative release to be live before admitting the next batch.
  • ci-passed — admit the next batch once exact-main CI passes; the deployment is still dispatched and followed, but a later reaction (or the scheduled reconciliation) carries it through to verification, records the watermark, and emits notifications.
• follow_release gains an admit_gate argument. In ci-passed mode it still dispatches the deployment at awaiting-deploy, then hands control back instead of blocking through deploy/verify. CI and deploy failures still short-circuit and pause exactly as before.
• command_react uses the gate at both the start-of-reaction hold and the end-of-reaction follow.
• Example policy, README, and reference docs document the option and its tradeoff.

The default path is provably identical to the previous behavior: with release_admission = "verified" the admitted-state set is {"verified"}, so the hold condition and exit check reduce to the original verified-only logic, and admit_gate defaults to "verified" everywhere.

Tradeoff (documented)

ci-passed trades a larger failure blast radius for throughput: because more than one batch can land before a deploy is verified, a deploy failure can implicate multiple batches, and verification/notifications for a release may be emitted by a later reaction rather than the merging one. It suits teams with fast, reliable, cumulative deploys.

Testing

• python3 -m unittest discover -s tests — 248 tests pass (4 new).
• python3 -m ruff check . — clean.

New tests cover: config parse + rejection + safe default; follow_release returning at the CI-passed gate while still dispatching the deploy; the reactor admitting the next batch at awaiting-deploy under ci-passed; and the reactor still holding at awaiting-deploy under the default.

Note

This is independent of the delivery-health metrics PR (#47) and is branched off main.