docs: document preboot deploys and forward-compatible migrations

[mroderick]

Summary

Production now runs with Heroku preboot, so a deploy no longer restarts all web dynos at once: new dynos boot first, traffic switches to them about 3 minutes after the deploy, and the old dynos shut down then. This PR writes down what that means for the two audiences whose deploy behaviour changes.

• CONTRIBUTING.md gains a "Deploys and preboot" section for anyone deploying: the ~3 minute switchover, that heroku ps shows only the new dynos during the overlap (old ones keep serving but do not appear in it), heroku ps:stop for a bad dyno, and when to temporarily disable preboot.
• AGENTS.md gains "Migrations and Heroku preboot": migrations must be forward-compatible because old code serves against the new schema for ~3 minutes after the release phase runs rake db:prepare. It covers expand/contract, ignored_columns before remove_column, two-step renames, the real meaning of safety_assured, and the disable-preboot escape hatch for migrations that cannot be made forward-compatible.

Related: #2949

Validation

• Preboot was enabled on codebar-production and confirmed with heroku features:info preboot (Enabled: true). Enabling the feature does not restart dynos.
• Docs-only diff: no test or lint surface.
• The two claims an adversarial review corrected (heroku ps behaviour and the boot-failure 503 case) were checked against the live Heroku preboot doc.
• Step 2 of Enable Heroku preboot for zero-downtime deploys #2949 (confirm the next deploy's logs show new dynos starting before old ones stop) is pending the next production deploy.

Post-Deploy Monitoring & Validation

No additional operational monitoring required for this diff (documentation only). The underlying production change (preboot) is validated at the next deploy per issue #2949 step 2: logs should show new web dynos starting before old ones stop, and heroku ps will list only the new dynos during the overlap.