test(dashboard): prove the Secrets nav gate exists, by its absence

The policy tests shipped at 1c30611 could not detect a deleted gate. They
assert that secrets:manage admits an Administrator and refuses a Viewer —
true, and library behaviour this repo did not author. The wiring is the
only thing that change introduced, and nothing covered it.

The point is sharper for repos where the link already existed before
gating, which includes this one: "an Administrator still sees it" is
identical to the pre-change behaviour, so it cannot distinguish a working
gate from an inert AuthorizeView. Only the negative observation proves a
gate is there at all.

SecretsNavRenderTests renders MainLayout through the framework's static
HtmlRenderer — no component-testing package, because the assertion is
about emitted markup rather than interactivity — and asserts:

- absent for a Viewer, and for an anonymous caller (the load-bearing pair)
- present for an Administrator (the control: without it, a rail that
  rendered nothing at all would satisfy both absence assertions and the
  suite would report a working gate over a blank page)
- the ungated API Keys sibling still present for a Viewer, so a later
  "consistency fix" that hides it fails loudly rather than silently
  removing read access

Confirmed non-vacuous by mutation rather than by argument: with the
AuthorizeView removed from the layout, both absence tests go red and all
three original policy tests stay green.

Build 0 warnings / 0 errors; suite 899/899 (895 + 4).

docs/plans/2026-08-11-dashboard-ui-sweeps.md

@@ -383,7 +383,28 @@ rule is "gate the link when the page denies the role outright", not "gate everyt
 refused, unauthenticated refused) in `SecretsNavGateTests`, and `/admin/secrets` joins the canonical
 route list in `GatewayApplicationTests` — it is the one nav destination mounted from an RCL rather
 than declared here, so a routing regression could remove it without touching this repo's pages.
-Not a rendering test: the suite has no component-testing harness, and adding one to assert a single
-`AuthorizeView` would be a large dependency for a small claim.
 
-**Verification.** Build 0 warnings / 0 errors; suite **895/895** (892 + 3).
+### 8a. Correction: the policy tests could not detect a deleted gate
+
+The coverage above shipped with a stated rationale — that rendering was disproportionate because the
+policy verdict "is the part that can actually be wrong". That rationale was wrong, and a review point
+from the OtOpcUa session identified why: the policy is library code this repo did not author, while
+the *wiring* is the only thing this change introduced. Worse, the check applies specifically to repos
+where the link already existed before gating — "an Administrator still sees it" is identical to the
+pre-change behaviour, so it cannot distinguish a working gate from an inert one. **Only the negative
+observation proves a gate exists at all.**
+
+`SecretsNavRenderTests` now renders `MainLayout` through the framework's static `HtmlRenderer` — no
+component-testing package needed, since the assertion is about emitted markup, not interactivity —
+and asserts the Secrets item is absent for a Viewer and for an anonymous caller, present for an
+Administrator, and that the ungated API Keys sibling stays present for a Viewer (so a later
+"consistency fix" that hides it fails loudly).
+
+**Confirmed non-vacuous by mutation**, which is the only thing that makes the absence assertions
+worth anything: with the `AuthorizeView` removed from the layout, `Rail_OmitsSecretsLink_ForViewer`
+and `Rail_OmitsSecretsLink_ForAnonymous` both go red — **and all three original policy tests stay
+green**, demonstrating the gap concretely rather than by argument. The Administrator case is retained
+as the control: without it, a rail that rendered no nav at all would satisfy both absence assertions
+and the suite would report a working gate over a blank page.
+
+**Verification.** Build 0 warnings / 0 errors; suite **899/899** (895 + 4).