feat(googlechat): migrate Google Chat trust config to first-class [googlechat] section (Phase 1)

[chaodu-agent]

Summary

Migrate Google Chat adapter trust configuration from gateway env vars to a first-class [googlechat] section in config.toml.

Current State

• Gateway env vars only (GATEWAY_ALLOW_ALL_USERS, GATEWAY_ALLOWED_USERS)
• No per-platform granularity for Google Chat

Target State

[googlechat]
allowed_users = ["users/123456789", "users/987654321"]
# allow_all_users = true  # explicit opt-in only

Tasks

• Add [googlechat] section to config schema
• Wire Google Chat trust through PlatformTrustConfigs registry
• is_bot derivation: message.sender.type == "BOT" (native field from Chat API)
• Deny-echo via spaces.messages.create (reply in same space)
• Deprecate gateway env vars for Google Chat
• Update docs and config.toml.example

Notes

• Sender ID format: user resource name (e.g., "users/123456789")
• L1 auth: JWT (RS256) verified via Google JWKS; email claim = chat@system.gserviceaccount.com

Refs

• Umbrella: umbrella: Phase 1 trust migration — per-platform [section] for all adapters #1356
• ADR: docs(adr): revise identity-trust-none — three-layer architecture #1291

[github-actions]

⚠️ This issue is missing the following required information and will not be processed until completed:

• Use Case

Please edit this issue to fill in the missing fields. Thank you!

Tip: Use headings like ## Description or ### Description — common synonyms (e.g. ## Problem, ## Reproduction, ## Motivation) are also accepted.

[canyugs]

Cross-checked this issue's claims against current main. The direction is correct and the described current state is accurate. A few notes for whoever implements this:

1. Follow the Telegram resolve pattern, not resolve_allow_all.
Two conflicting semantics coexist in-tree: Discord's wiring uses resolve_allow_all(flag, list) = flag.unwrap_or(list.is_empty()) (no flag + empty list → allow all), while TelegramConfig::resolve() uses unwrap_or(false) (deny-all default, per the identity-trust-none ADR). The [googlechat] section must copy the Telegram pattern — including allowed_users: None = fall back to env vs Some([]) = explicit deny — or an empty section silently opens the bot to everyone.

2. Document the exact-match ID format prominently.
The trust gate matches event.sender.id, which the adapter sets to the full resource name (users/123456789). But the sender_name exposed downstream is the bare numeric ID with the prefix stripped, so operators will naturally paste bare numbers into allowed_users and never match. Either normalize during resolve (auto-prefix bare numerics) or call it out in docs / config.toml.example. (The deny-echo prints the full users/… ID, so copy-paste from the echo works.)

3. Two checkboxes are already done or near-zero cost.
is_bot derivation: the adapter already checks sender.type == "BOT" and drops at the webhook layer — though note this means trusted_bot_ids can never admit a Google Chat bot; if unified bot gating is the intent, the adapter should emit is_bot = true instead of dropping. Deny-echo: DenyIdentity → unified reply routing → spaces.messages.create already works end-to-end incl. thread_id; this needs a test, not implementation.

4. One dependency worth knowing: Google Chat's L1 (JWT verification) is only enabled when GOOGLE_CHAT_AUDIENCE is set — without it the webhook accepts unauthenticated POSTs, so the L3 allowlist is forgeable. That's an umbrella-level concern (likely not unique to Google Chat); raised on #1356.