docs(plans): annotate the r3 register — browse-transit-below-realm-root closed by 89630ee4+ff9d617a

docs/plans/2026-08-17-perf-followups-r3.md

@@ -818,6 +818,17 @@ round-2 register. **None of these blocks the branch.**
   Client.CLI's own default recursive browse. Discovered by the T7 live gate. **RECOMMEND filing a
   Gitea issue before anyone enables `Security:Acl:Enabled` in production.** Likely fix: mark the
   realm-root container browse-transit whenever any grant resolves beneath it.
+  - **Closed by `89630ee4` + `ff9d617a` (branch `fix/acl-anchor-browse-transit`, 2026-08-18)** — no
+    Gitea issue needed; fixed directly. The actual mechanism was one step off the guess above: the
+    trie's zero-segment realm-root branch already existed and was correct — nothing ever *produced*
+    that scope, because the shared anchor's identifier (`s=OtOpcUa`, now `V3NodeIds.SharedRootFolderId`)
+    split into a one-segment scope no grant path contains. `DataPlaneAuthorizer.BuildScope` now maps
+    the anchor (realm-qualified: Raw namespace only) onto the zero-segment scope, and `Evaluate` adds
+    a Browse-only second walk against the zero-segment **Uns** scope — the single anchor fronts both
+    trees, so a UNS-only grant holder must also get through. 11 new tests (3 trie pins, 7 authorizer
+    incl. falsification of the OR-leg and of the realm qualification, 1 e2e browse-succeeds-and-still-
+    filters through a booted server). Full high-risk chain: spec ✅, code CHANGES REQUESTED (stale
+    "two namespace root folders" XML remark) → fixed → delta re-APPROVED.
 - **`ns=0` standard nodes are ungated — the boot warning overstates.** With the gate on, both
   the key and anonymous read `i=2256` and browse `i=2253` successfully: those are served by the
   SDK's `CoreNodeManager` and never reach `DataPlaneAuthorizer`. Defensible (standard server