docs: mesh gRPC ingress is AllowAnonymous; the PSK interceptors are the gate (R3-01)

New docs/security.md section "Mesh gRPC ingress is AllowAnonymous by design"
(archreview 03/S14): what the cookie FallbackPolicy covers, why it can block a
correctly-PSK'd call before the interceptor's verdict matters, why the
AllowAnonymous opt-out is safe (all five interceptors fail-closed), the
affected-endpoint table (fused-vs-driver-only distinction), and the two
standing guards (MeshGrpcAnonymousMetadataTests, MeshGrpcMapConventionTests)
plus the auth-stack/driver-only boundary tests.

One cross-reference line each in docs/Configuration.md (§MeshTransport,
§ConfigSource/ConfigServe) and docs/Telemetry.md, so an operator reading
about the listener ports meets the constraint where they'd look for it.

docs/Telemetry.md

@@ -190,6 +190,14 @@ transports. ScadaBridge itself has since closed that gap with this identical
 interceptor pattern, so Phase 5 ships authenticated from the start rather than deferring auth to a
 later hardening pass. See the design doc's superseded note for the full history.
 
+**On a fused `admin,driver` node, `TelemetryStreamService` and `NodeCommandService` are `AllowAnonymous`
+by design** — a *different* gate from the interceptor above. `TelemetryStreamAuthInterceptor` is the PSK
+check; on an admin-role node the AdminUI cookie `FallbackPolicy` sits in front of it and would 401/redirect
+a correctly-keyed call before the interceptor's verdict matters, because it runs in the authorization
+middleware, strictly *before* the interceptor executes (archreview 03/S14). A driver-only node never
+registers that middleware at all, so it is structurally unaffected either way. See
+[`security.md` § Mesh gRPC ingress is `AllowAnonymous` by design](security.md#mesh-grpc-ingress-is-allowanonymous-by-design).
+
 ## Upgrading an existing deployment: populate `ClusterNode.GrpcPort` first (#493)
 
 `GrpcPort` is a **nullable column added by Phase 5**, and nothing backfills it onto rows that