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/GatewayConfiguration.md

@@ -273,6 +273,14 @@ staging rig, e.g. one pointed at the plaintext shared GLAuth). A production-like
 deployment must therefore run with the literal `Production` environment name for
 the hard-stops to apply.
 
+`windev` (`10.100.0.48`) is deliberately labelled `Staging` (its NSSM
+`DOTNET_ENVIRONMENT` entry, set 2026-08-07) rather than left at the `Production`
+default. It is the permissive rig the parenthesis above describes: it runs
+`Dashboard:DisableLogin=true` and binds the shared GLAuth, which offers no TLS,
+so a `Production` label would contradict its own configuration and both
+hard-stops would refuse the boot. Label a host `Production` only when its
+configuration can satisfy them.
+
 ## Secrets Master Key
 
 `${secret:...}` tokens in configuration — currently just