fix(exposure): check SSO RBAC and NetworkPolicies in preflight (#47)

The preflight is the documented gate before real SSO traffic, but it did
not check two things the dsh-demo install got wrong:

- The gateway Role must grant `patch` on
  extensions.agents.x-k8s.io/sandboxclaims. The SSO landing path rotates
  the claim's token-hash annotation whenever the browser has no valid
  gateway session (first visit, expired or foreign cookie, gateway
  restart), so a missing verb makes every such sign-in answer 503.
  Verify with `kubectl auth can-i --as`; when a read-only kubeconfig
  cannot impersonate, fall back to reading the rules of the Role (or
  ClusterRole) the RoleBinding points at.
- The variant's NetworkPolicies must be applied. Without them any Pod in
  the cluster can reach dsh-gateway:8080 and spoof X-Forwarded-User, so
  the exposure is demo-only. Fail the preflight while either policy from
  75-networkpolicies.yaml is missing.

Also fix a false positive in the cookie-secret check: oauth2-proxy accepts
16, 24 or 32 raw bytes, or URL-safe unpadded base64 that decodes to one of
those lengths (pkg/encryption.SecretBytes). The documented
`secrets.token_urlsafe(32)` value is 43 base64 characters that decode to 32
bytes, so it is valid and must not be reported as 43 raw bytes.

The docs that enumerate the preflight checks are updated to match, and
75-networkpolicies.yaml notes that the preflight enforces it.

Verified with shellcheck, yamllint, make check and the gateway test suite
(150 passed); the new checks were exercised read-only against the live
dsh-demo cluster.

Entire-Checkpoint: 01M6FNY2WTC4GMAJ8BAHABN88M

Co-authored-by: SREDevOpsAgents <agents@sredevops.org>

examples/dsh-agents-as-a-service/docs/optional-hardening.md

@@ -338,8 +338,10 @@ The SSO policy is what turns the trust boundary in the
 The `dsh-gateway` Service must still stay ClusterIP; do not apply both exposure
 variants. After applying the SSO variant, run
 [`scripts/preflight-sso.sh`](../scripts/preflight-sso.sh): it checks the
-gateway's SSO env, the Secrets, the TLS reference, leftover placeholders and
-accidental second paths (such as an Ingress).
+gateway's SSO env, the Secrets, the TLS reference, leftover placeholders,
+accidental second paths (such as an Ingress), the gateway Role's `patch` verb on
+`sandboxclaims` (SSO token rotation) and that both SSO NetworkPolicies are
+applied.
 
 Verify the negative case from a sandbox pod (it is not the proxy):