P1: Implement pinned OCM ClusterGateway snapshot transport

[gnanirahulnutakki]

Parent: #9

Implement the concrete hubfleet.Transport adapter over OCM ClusterGateway plus managed-serviceaccount projected credentials. The adapter must collect the existing bounded normalized inventory/health snapshot from registered spokes without adding a hub-side list/watch loop or storing/logging a token, kubeconfig, endpoint, or raw Kubernetes object.

Acceptance:

• works through OCM cluster-proxy + MSA against two registered spokes in the existing M0 lab
• pins the registered managed-cluster reference and allowed service/API route; no arbitrary endpoint selection
• handles projected-token rotation and bounded per-spoke timeouts
• proves least-privilege negative RBAC controls and retained stale coverage on one failed spoke
• includes unit, PostgreSQL/RLS, and real multi-cluster integration evidence

Out: hub listener/UI, arbitrary list/watch, new tunnel/agent, actions, and persistent credentials.

[gnanirahulnutakki]

Blocked by #104.

M0 now proves the pinned ClusterGateway add-on can reach both spokes and that its MSA is locally Pod-only. However, the real Sith hub reader (limited to get clustergateways/proxy) still receives HTTP 200 for the gateway Secrets route because ClusterGateway v1.3.1/1.3.2/1.4.0 forwards inbound Authorization ahead of its MSA credential. The regression test is privacy-safe and does not emit bodies.

No transport code will be committed or merged until #104 is resolved and the exact M0 two-spoke negative test returns 403.

[gnanirahulnutakki]

Upstream remediation is now oam-dev/cluster-gateway#171. Its signed commit 5bd9423 passed hosted unit, standard ClusterGateway end-to-end, and OCM add-on end-to-end checks.

This issue remains blocked until an official upstream release is available. At that point, repin the official artifact and run the existing two-spoke least-privilege regression; the fixed Secrets route must return 403 before any Sith transport code is committed.

[gnanirahulnutakki]

2026-07-13 security monitor: remain blocked by #104. Upstream ClusterGateway PR #171 is green and mergeable but still open; the latest official release is still v1.9.1 and does not supply the authorization-isolation fix. Sith PR #121 records this gate. Do not implement or consume the transport until an official upstream release exists, then rerun the two-spoke negative Secrets route expecting 403.

[gnanirahulnutakki]

Status update: #123 shipped the independent direct ClusterProxy/Konnectivity alternative through #124 (fc8ca6e on dev). This issue remains open and blocked exactly as specified: its ClusterGateway-specific transport still requires #104 in an official upstream release.