T10.9: rollback-aware deploy runbook for the Okta cutover

New DEPLOY-runbook-2026-09-03.md, separate from the 2026-08-04 runbook.
Names the five new OKTA_* env vars, treats the pre-deploy backup as the
only way back once 1d60a608bb51 (drop_local_password) commits since its
downgrade() restores the column but not the data, and splits Rollback
into the fixable case (Okta app integration misconfigured, fix and
redeploy api, no data at risk) versus the severe case (abandoning Okta
for local-password code, which only a destructive backup restore can
reach). States D16's no-break-glass posture plainly.

D17 records the decision and why: staged-deploy-sequence docs and
backlog-only were both considered and declined in favor of the runbook.

Logged to backlog.md rather than fixed here: okta_auth.describe() has
no caller (BL-028), users.failed_attempts/locked_until are vestigial
(BL-029), DEPLOY-login-portal.md is fully stale (BL-030).

docs/waves/wave-10.md

@@ -120,6 +120,31 @@ Depends only on `main` as it stands after `D15`. Not sequenced behind any other
 - **T10.8 — Verification.** 390px and 1440px, full suite, done-when checks per task,
   matching the rigor D13 was held to.
 
+- **T10.9 — Rollback-aware deploy runbook.** Raised after hazard review found
+  `DEPLOY-runbook-2026-08-04.md`'s Rollback section has no case for a migration whose
+  `downgrade()` cannot restore the data it drops — see `D17`. `T10.4`'s
+  `1d60a608bb51_drop_local_password` is exactly that: the schema comes back, the
+  bcrypt hashes do not.
+
+  Built: `DEPLOY-runbook-2026-09-03.md`, following the 2026-08-04 runbook's structure
+  (fill-in table, numbered deploy steps, case-by-case Rollback section, Notes). Names
+  the five `OKTA_*` vars as newly required (the precedent's "no new environment
+  variables" note does not carry over), treats the pre-deploy backup as the only way
+  back once the migration commits, and splits Rollback into the fixable case (Okta app
+  integration misconfigured — fix and redeploy `api`, no data at risk, migration stays
+  applied) versus the severe case (abandoning Okta for local-password code — only the
+  destructive backup restore gets there, reusing the 2026-08-04 runbook's own Case C
+  procedure). D16's no-break-glass posture is stated plainly rather than left implicit.
+
+  Logged, not fixed here (out of scope): `okta_auth.describe()`'s startup log line
+  (referenced by `DEPLOYMENT.md`/`server/README.md`) has no caller anywhere in
+  `server/app.py` — nothing actually prints it at process start. The runbook's Step 4
+  therefore verifies via a live Okta sign-in rather than a log line, and this gap is
+  flagged in `docs/waves/backlog.md` as a candidate fix (wiring `describe()` into
+  startup) since it directly bears on deploy verifiability. `DEPLOY-login-portal.md`
+  is now fully stale (bcrypt, `create-admin --password`, none of which still exist) —
+  not touched, no task claims it.
+
 ## Still open
 
 - The OIDC claim mapping (`T10.3`).