Deployment rollback compatibility

Webhook header storage v1 is a deployment rollback boundary. A forward deployment applies the database migrations, rolls out the compatible backend, waits for the new task to become healthy and the old tasks to drain, and then runs the bounded header backfill.

Before a rollback changes any service, the candidate backend image must pass the explicit webhook-header-storage-v1 capability probe. Compatible rollback images skip forward Alembic migrations and the forward-only backfill, then use the normal health-gated rollout. Images that do not advertise the capability are rejected before migration or service update; there is no override for this check.

Recovery to a build before webhook header storage v1 is therefore roll-forward only. The database write-generation guard remains active during coexistence so older writers cannot silently promote changed headers to the current storage version.

Deployment manifests keep the historical target in the backwards-compatible commit_sha field and the explicit target_commit_sha field. The current trusted deployment controller is recorded separately as orchestrator_sha. Forward manifests set all three to the same SHA; successful rollback manifests set commit_sha and target_commit_sha to the historical target while keeping the current orchestrator SHA. Older rollback manifests are read through their rollback_of parent to recover the target identity before another rollback is started.