Rebase migration PRs before release and verify detached deployments separately

Migration PRs that share an append-only ledger must be rebased after any competing migration lands, and their generated migration suffix/snapshot must be regenerated from the new base before merge. This avoids two different migrations claiming the same ledger position. Separately, when a release workflow submits deployment with a detached command, workflow success proves migration and upload acceptance—not runtime health—so poll the exact provider deployment to success and then probe application readiness. This method applies to ordered migration ledgers and detached deployment clients; it does not imply every migration system uses numeric filenames or every deploy command returns early.

Evidence/example — 2026-09-11

In the Shield repository rollout audit for COR-4193/PR #850, current staging acquired 0122_cor_3957_protect_cleanup_ledger while the open PR independently contained a different 0122 migration, producing journal/snapshot conflicts during update. Repository source .github/workflows/staging-release.yml also used railway up --detach after its guarded migration. Provenance: local checkout of current origin/staging, PR branch diff, and repository deployment workflow/runbook inspected read-only on 2026-09-11. No migration or deployment was changed during the audit.