fix(mesh): stop reporting override-keyed clusters as REVOKED (lmxopcua#784)

The docker-dev centrals logged "Mesh PSK secret ot-mesh-psk-<cluster> ... is
absent (or blank) in the store; the key is REVOKED" for every cluster on every
contact refresh, while every gRPC dispatch and ack authenticated.

Investigated: not an auth bypass. The rig supplies each cluster's key through
MeshTransport:ClusterPsks (central side, equal to that cluster's nodes'
MeshTransport:GrpcPsk) and seeds nothing in the store. TryGetPsk/Matches consult
the override first on every call, so enforcement was on; only RefreshAsync read
the store for those clusters regardless and logged a revocation that never took
effect. RefreshAsync now skips clusters covered by a non-blank override, so the
REVOKED warning is only logged for a cluster that genuinely has no key.

Test pins it with a positive control (a cluster with no override is still read,
warned about and refused) and enforcement on the override key (wrong token
rejected). Mutation-checked: removing the skip fails the test.

Claude-Session: https://claude.ai/code/session_01GT67AEHd2Acv1YPwGfXEoV

docs/reviews/2026-10-21/gates.md

@@ -190,6 +190,12 @@ hold.
    absent (or blank) in the store; the key is REVOKED — commands to that cluster and acks from it are refused`. Yet
    every gRPC dispatch and ack in these runs succeeded. Either the rig's PSK secrets are not seeded and enforcement is
    off, or the warning is stale. Not investigated.
+   **Resolved (lmxopcua#784): the warning was false, not a bypass.** The rig's centrals supply all three keys
+   through `MeshTransport__ClusterPsks__{MAIN,SITE-A,SITE-B}` (each equal to that cluster's nodes'
+   `MeshTransport__GrpcPsk`) and seed nothing in the store. `MeshPskProvider.TryGetPsk` consults that override
+   first on every lookup, so enforcement was on and every call authenticated against the override key; only
+   the background `RefreshAsync` read the store for those clusters anyway and reported them revoked. The
+   refresh now skips override-covered clusters, so `REVOKED` is logged only for a cluster with no key at all.
 3. **A surgical raw-tag add respawns that driver.** The driver's spawn spec carries its tag set, so adding one tag
    reconnects the whole driver (the accepted cost noted in `DriverSpawnPlanner`). On a live subscriber this shows as
    one `BadNoCommunication` sample (< 1 ms) on every value of that driver, including UNS references and virtual tags