docs: record that merging to main promotes production (#975)

The cutover plan told the operator to prepare the website deployment without
promoting it, and sequenced Task 11 around blocking forms before the hard
boundary went live. Neither is possible here: threadplane promotes every main
deployment automatically and main is the only branch that has ever reached
production. Merging #968 promoted the boundary seconds later, ahead of the
firewall block, drain, snapshot, import, and cancellation.

Annotates both affected steps and states the constraint in the runbook so a
future cutover either disables auto-promotion first or reconciles provider
state before the code merges.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Author: blove

docs/superpowers/plans/2026-09-02-growth-hard-cutover.md

@@ -994,6 +994,12 @@ Deploy the merged commit, verify unauthenticated rejection and authenticated rea
 
 - [ ] **Step 6: Prepare—but do not promote—the website deployment**
 
+> **This step is not achievable on this project and was never verified before it was written.** The `threadplane` Vercel project promotes every `main` deployment automatically; `main` is the only branch that has ever reached production, across at least the last 40 production deployments. Merging the cutover pull request therefore *is* the promotion, and it happened seconds after #968 merged on 2026-09-03, before any firewall block, drain, snapshot, import, or cancellation had run.
+>
+> Task 11's ordering depends on the same false assumption: it blocks form ingress, reconciles the legacy provider state, and only then promotes the hard boundary. On this project the boundary is already live the moment the code lands.
+>
+> Any future cutover of this shape must either disable automatic production promotion on the project first, or be re-sequenced so the legacy provider inventory is imported and cancelled **before** the code merges.
+
 Build/deploy the merged website artifact with `growth_v1`. Verify configuration, database reachability, lifecycle reachability, and bundle absence of legacy code on its deployment URL. Do not route production form traffic to it yet.
 
 - [x] **Step 7: Prepare and verify the rollback control before cutover**
@@ -1043,6 +1049,8 @@ If any condition fails, keep the firewall and all campaign switches off. Follow
 
 - [ ] **Step 6: Promote the hard-boundary website while forms remain blocked**
 
+> Superseded on this project — see the note on Task 10 Step 6. Promotion is automatic on merge, so there is no separate promote to hold until forms are blocked.
+
 Promote the prepared website deployment. Verify production is on the merged commit, `growth_v1` is active, and static/runtime probes find no NDJSON, Loops, Audience, direct send, or provider scheduling path.
 
 - [ ] **Step 7: Reopen forms and capture the immutable cohort instant**

docs/superpowers/runbooks/2026-08-31-growth-lifecycle-cutover.md

@@ -2,6 +2,12 @@
 
 Status: **LOCAL implementation and harness only.** No disposable database, preview, or production action in this runbook has been performed. No Neon migration/import, Resend/Google read or write, Vercel deployment, Dawn deployed request, or switch change is implied by local test results.
 
+## Deployment promotion is automatic
+
+The `threadplane` Vercel project promotes every `main` deployment to production automatically, and `main` is the only branch that has ever reached production. There is no "build but do not promote" state for the website: **merging is promoting.** Sequence any cutover around that, and never write a step that depends on holding a merged commit back from production.
+
+The `threadplane-lifecycle` project behaves the same way on `main`.
+
 ## Gate classes
 
 - **LOCAL**: repository-only and safe with fake fixtures; no provider or database connection.