wave-10: close out claim mapping and redirect URI, live in production

Confirmed by an actual live Okta sign-in after main (cc64c88) deployed: preferred_username is the right identity claim, and the redirect URI works. Matt matched his existing pre-Okta admin account rather than getting JIT-provisioned as a duplicate. Two deploy-time snags recorded, both Case B (config, not data): OKTA_CLIENT_ID/SECRET/ISSUER left empty in Portainer at first (caught cleanly by is_configured()), then OKTA_ISSUER missing its https:// scheme (surfaced as httpx.UnsupportedProtocol, not a deliberate app error - BL-028 still stands). Neither needed the backup. BTG pilot group now includes Cody and Cameron, awaiting Adrian.

docs/waves/wave-10.md

@@ -201,10 +201,33 @@ Depends only on `main` as it stands after `D15`. Not sequenced behind any other
 
 ## Still open
 
-- The OIDC claim mapping (`T10.3`).
+- The `Business Technology Group` pilot assignment in Okta. Originally six names
-- Final confirmation of the redirect/callback URI (`https://wp.controls.dev/api/auth/okta/callback`
+  (Carlee Swihart, Drew Hilliard, Matt Mabrey, Nick Siegfried, Rachel Schreiber, Terry
-  proposed, pending security).
+  Sajan); Cody and Cameron added 2026-09-09. Adrian added only Matt at first,
-- The `Business Technology Group` pilot assignment in Okta.
+  deliberately, pending the live sign-in confirmation below — awaiting his response to
+  add the rest of the group now that it has.
 
 Closed since first written: admin bootstrap and break-glass posture, previously open
 questions, decided in `D16` (2026-09-03) and folded into `T10.4` above.
+
+**Closed 2026-09-09, live in production:** the redirect/callback URI
+(`https://wp.controls.dev/api/auth/okta/callback`) is confirmed working, and so is the
+OIDC claim mapping (`T10.3`) — `preferred_username` (the code's documented default,
+never actually confirmed by name in Request 50649's thread) is correct, no
+`OKTA_IDENTITY_CLAIM` override needed. Both settled by an actual live sign-in against
+the real Okta tenant after `main` was merged (`cc64c88`) and deployed: Matt signed in
+as himself, matched his existing pre-Okta admin account by `find_user()` rather than
+JIT-provisioning a duplicate (the account already existed — this app has ~40 real
+users, not the seeded test fixture), landed on `index.html` signed in, admin role and
+project access untouched. One real deploy-time snag on the way, worth recording since
+it's exactly the Case B scenario `DEPLOY-runbook-2026-09-03.md` anticipated: the first
+redeploy left `OKTA_CLIENT_ID`/`OKTA_CLIENT_SECRET`/`OKTA_ISSUER` as empty rows in
+Portainer (env var names added, values never filled in) — caught via
+`is_configured()`'s all-four-required check failing closed (the 503 "Sign-in is
+temporarily unavailable"), not silently. A second snag after filling those in:
+`OKTA_ISSUER` was pasted without its `https://` scheme, which surfaced as
+`httpx.UnsupportedProtocol` from Authlib's OIDC discovery fetch rather than anything
+the app's own code raises deliberately — the exact case the runbook's Notes flagged as
+having no startup-time confirmation (`okta_auth.describe()` still has no caller,
+`BL-028`). Both fixed by correcting the env var values in Portainer and redeploying;
+neither needed the backup or the database.