docs(sec-36): record the completed windev dashboard verification

SEC-36's primary check -- dashboard /login through the real DashboardAuthenticator
search bind -- was deferred because windev's gateway was crash-looping on the stale
deployment filed as NEXT-07. That host was redeployed 2026-08-07, so the check ran:
login as multi-role returns 302 with the dashboard cookie and the authenticated page
renders the admin nav, while an anonymous control still redirects to /login. The
rotated service-account credential is now proven end-to-end on the deployed host, not
only by the equivalent ldapsearch primitive, and the runbook's Correction 3 is past
tense throughout rather than describing a fault that no longer exists.

Also record why windev runs the Staging environment name. The redeploy tripped SEC-06's
Production hard-stop on Ldap:Transport=None, and windev cannot satisfy it: it binds the
shared GLAuth, which offers no TLS, and runs Dashboard:DisableLogin=true. The Production
label contradicted its own configuration, so the host was relabelled rather than the
guard weakened -- exactly the permissive-staging-rig case the SEC-35 section already
carves out.

docs/runbooks/SEC-36-ldap-credential-rotation.md

@@ -28,17 +28,23 @@
 >
 > **Correction 3 — step 4's dashboard verification is deferred on `10.100.0.48`; a direct bind was
 > used instead.** The NEW value **is** staged on windev (added as the 10th `AppEnvironmentExtra`
-> entry on the `MxAccessGw` NSSM service), but dashboard `/login` could not exercise it: windev's
-> gateway is **crash-looping on a pre-existing, unrelated fault** — the deployed Server binary
+> entry on the `MxAccessGw` NSSM service), but dashboard `/login` could not exercise it at rotation
+> time: windev's gateway was **crash-looping on a pre-existing, unrelated fault** — the deployed Server binary
 > (2026-06-25) predates the auth-DB migration of 2026-07-15, so it opens a schema-version-3 database
 > it only supports at version 2 and aborts at startup (~10k Hosting-failed events/day since at least
-> 08-06). This is a stale-deployment problem, not a rotation problem; it is filed as a next-cycle
-> finding. **Verification used instead:** a direct `ldapsearch` bind as
+> 08-06). That was a stale-deployment problem, not a rotation problem; it was filed as next-cycle
+> finding NEXT-07 and resolved by redeploy on 2026-08-07. **Verification used instead:** a direct `ldapsearch` bind as
 > `cn=serviceaccount,dc=zb,dc=local` with the new value against `10.100.0.35:3893` succeeded and
 > returned the `multi-role` entry — which is precisely the search bind the dashboard performs, minus
-> the HTTP shell. **Finish the deferred check when windev is repaired:** redeploy a current Server
-> build (or restore a schema-2 auth DB), then browse the dashboard `/login` as `multi-role` per
-> step 4.
+> the HTTP shell. **The deferred check was completed 2026-08-07**, once windev was repaired by the
+> redeploy filed under NEXT-07. With `Dashboard:DisableLogin=false` supplied as a process-env-only
+> override on a foreground run of the new build, `GET /login` returned 200 with an antiforgery token,
+> `POST /auth/login` as `multi-role`/`password` returned 302 to `/` with a `MxGatewayDashboard`
+> cookie, the authenticated `GET /` rendered the admin nav, and an anonymous control redirected to
+> `/login?ReturnUrl=%2F` — so the rotated credential is proven through the real
+> `DashboardAuthenticator` search-bind path on the deployed host. As deployed, windev keeps
+> `DisableLogin=true`, so routine operation there does not exercise LDAP; the standing regression
+> proof is `DashboardLdapLiveTests` (5/5 green against `10.100.0.35` since commit `de67b45`).
 >
 > **Correction 4 — the lockout caution under "Verifying the rotation" is inert for this instance.**
 > It warns that GLAuth's 3-fail / 10-minute per-IP lockout can lock the whole office when testing