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 (feat(trust): [wecom]/[googlechat]/[teams] first-class trust sections (Phase 1) #1366)
• Wire Google Chat trust through PlatformTrustConfigs registry (feat(trust): [wecom]/[googlechat]/[teams] first-class trust sections (Phase 1) #1366 — embedded/unified path)
• is_bot derivation: implemented — user_type == "BOT" from the native Chat API field (adapters/googlechat.rs:564); bot events are dropped pre-dispatch, so the InboundEvent.is_bot field is false-by-construction downstream
• Deny-echo: handled by the platform-generic unified gate path (gateway.rs DenyIdentity → throttled request-access echo via the adapter's send_message, which posts through spaces.messages.create)
• Deprecate gateway env vars for Google Chat (feat(trust): [wecom]/[googlechat]/[teams] first-class trust sections (Phase 1) #1366)
• Update docs and config.toml.example (feat(trust): [wecom]/[googlechat]/[teams] first-class trust sections (Phase 1) #1366)

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

[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.

[thepagent]

All tasks complete — trust section + registry wiring + docs shipped in #1366, full config-first parity (credentials/audience/webhook path) in #1383, and the two remaining boxes were already satisfied by existing code: is_bot derives from the native Chat API user.type field (adapters/googlechat.rs:564, bots dropped pre-dispatch), and deny-echo is handled by the platform-generic unified-gate path (DenyIdentity → throttled echo via send_message).

Residual gap — standalone-gateway deployments don't route through the shared gate yet — is platform-generic (Phase 1c), tracked on #1356, not Google Chat-specific. Closing.

[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.