docs(secrets): gRPC hub implementation plan (9 tasks, subagent-executable) + cached-on-sites posture made explicit

Plan + tasks ledger for scadaproj#3 execution: package (proto/server/client/
tests/publish 0.4.0), ScadaBridge wiring + live gate, OtOpcUa pair-local
re-gate, closeout. GAPS + runbook now state the gRPC mode keeps the
cached-on-site-clusters last-known-good posture (owner-confirmed).

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

ZB.MOM.WW.Secrets/docs/operations/clustered-secrets.md

@@ -201,7 +201,10 @@ Which topology each app runs in production is decided — tracked as
   the DB directly — they talk to central for everything — so the SqlServer hub's site-side
   connection string violates the topology rule. A `ZB.MOM.WW.Secrets.Replicator.Grpc` package
   (central-hosted `secrets_hub.v1`, **pull-only: updates originate at central only, by design**)
-  replaces it; until that ships, ScadaBridge replication stays off.
+  replaces it; until that ships, ScadaBridge replication stays off. The gRPC mode is **cached on
+  the site clusters** exactly like §2's hub mode — each site node keeps a full local store,
+  serves last-known-good secrets while central is unreachable, and converges on the first
+  successful sweep.
 - **KEK: one fleet-wide production KEK, delivered per node via appsettings/environment override,
   never committed.** The committed dev KEK is dev-only. Verify per pair with the §0 digest
   compare. A single fleet KEK is what makes bundle-based seeding between pairs possible.