feat(ui): Setup GCP — pairing requests + channels admin (Pieza 2/3)

[sitiouno]

Summary

Adds a Setup GCP item to the Console sidebar of the openclaw-office fork. From this page, HQ operators can:

• Approve / reject pending pairing requests from new branch nodes that have published themselves over the Tailscale VPN.
• Manage notification channels (Telegram first) backed by GCP Secret Manager — create, set-secret, test, enable/disable, delete.

This is Pieza 2/3 in the SitioUno alignment plan. The backend (Pieza 1) is sitiouno/gcloud-office#1 — that PR adds /v1/pairing/* and /v1/channels/* to the fleet-registry-api Cloud Run service. This PR is the operator-facing UI that drives those endpoints.

Pieza	Repo	Scope	Status
1	sitiouno/gcloud-office	API + SQL + scripts	merged-pending
2/3	this PR	Setup GCP UI (pairing list + channels CRUD)	here
4	sitiouno/gcloud-office	Capablanca HQ runner notify hookup	next

Architecture decisions

• REST, not gateway WebSocket. The existing gateway adapter has no REST proxy and is scoped to a single OpenClaw node, while pairing/channels are HQ-Cloud admin operations against a separate Cloud Run service. The new client lives in src/lib/registry-api-client.ts and is invoked directly from a Zustand store; it does not go through getAdapter().
• Config resolution mirrors the gateway pattern. VITE_REGISTRY_API_URL / VITE_REGISTRY_API_TOKEN at build time, or window.__OPENCLAW_CONFIG__.registryApiUrl/Token injected at runtime — same pattern src/App.tsx uses for gatewayUrl/gatewayToken. No URL hard-coded.
• Token never touches localStorage. The admin token is a server-side credential; it lives only in the env / runtime config object.
• Secrets stay on the server. The UI sends secret_value to POST /v1/channels/{id}/secret, then forgets it — the field is local component state, not Zustand state, and is cleared after submit. A read-only notice on the page reminds the operator.
• Existing Channels page is preserved. That page wraps the Gateway-managed transport channels (WhatsApp pairing, etc.), which are a different concept from the registry-managed alerting channels. To avoid confusing the two, the Channels page now shows a small banner that links to Setup GCP for Telegram alerts. The telegram entry in src/lib/channel-schemas.ts was extended with the required chatId text field, so any future Channels-side flow that re-uses that schema picks it up automatically.

Files added

• src/lib/registry-api-client.ts — typed REST client (pairing.*, channels.*), env/runtime config resolution, RegistryApiError + RegistryApiNotConfiguredError.
• src/lib/__tests__/registry-api-client.test.ts — covers config resolution, bearer header, JSON body, error mapping, and not-configured behavior.
• src/store/console-stores/setupgcp-store.ts — Zustand store with separate loading/error/in-flight state for pairing and channels.
• src/components/pages/SetupGcpPage.tsx — page shell with two tabs (Pairing Requests / Notification Channels) and the Secret Manager notice.
• src/components/pages/SetupGcpPage.test.tsx — render smoke + not-configured hint test.
• src/components/console/setupgcp/PairingRequestsView.tsx — status-filter chips, expandable rows, Approve/Reject (with reason) actions.
• src/components/console/setupgcp/ChannelsAdminView.tsx — channel list, Create dialog (with chat_id + bot token for telegram), set-secret form, test button with inline result, enable/disable, delete.
• src/components/console/setupgcp/SecretManagerNotice.tsx — read-only "secrets stay in GCP" panel.

Files modified

• src/components/layout/ConsoleLayout.tsx — new Cloud sidebar item between Cron and Settings.
• src/App.tsx — /setup-gcp route + PAGE_MAP entry.
• src/gateway/types.ts — PageId gains "setupGcp".
• src/components/pages/ChannelsPage.tsx — banner pointing to Setup GCP for Telegram alerts.
• src/lib/channel-schemas.ts — telegram now requires chatId alongside botToken.
• src/i18n/locales/{en,zh}/layout.json — consoleNav.setupGcp, pageTitles.setupGcp.
• src/i18n/locales/{en,zh}/console.json — full setupGcp.* tree, channels.fields.chatId, channels.placeholders.chatId, channels.gcpNotice.*.
• src/vite-env.d.ts — declares VITE_REGISTRY_API_URL + VITE_REGISTRY_API_TOKEN.
• .env.example — example block for the new env vars (no real values).

Validation

• npm run typecheck — clean.
• npm test — 483/483 passing (57 test files), including the 7 new tests.
• npm run build — production build succeeds.
• oxlint src/ — no new warnings introduced (3 pre-existing warnings unchanged).
• No new runtime dependencies added; only existing lucide-react, react-i18next, react-router-dom, zustand.

Test plan

• Build + serve locally with VITE_REGISTRY_API_URL and VITE_REGISTRY_API_TOKEN pointing at the staging fleet-registry-api → Setup GCP loads pending requests, approve flow returns 200.
• Create a Telegram channel from the UI → secret_ref becomes notification-channel-telegram-{id}, Test button delivers a message.
• Toggle enable/disable → reflects on next list fetch.
• Without env vars set → page shows the "Registry API not configured" hint and does not 401-spam.
• Inject window.__OPENCLAW_CONFIG__ = { registryApiUrl, registryApiToken } at runtime via bin/openclaw-office.js template → behaves identically to the env-var path.

Screenshots

(to be added once the staging fleet-registry-api PR #1 is deployed and a real Telegram channel can be exercised)

Out of scope

• Wiring the Capablanca HQ runner to actually consume notification_channels (Pieza 4, gcloud-office repo).
• A REST-over-gateway proxy that would let regular branch operators see channels (not needed; this is HQ-only).
• Smoke-test from the UI (POST /smoke-test exists in the API but requires the operator to paste the delegation token; deferred to a follow-up).

🤖 Generated with Claude Code