The Chat API publishes events with one of three envelope shapes
depending on how the bot is configured:

1. Workspace Add-ons (canonical, ce-type-driven):
   {"chat": {"messagePayload": {"message": {...}, "space": {...}}}}

2. Native Chat API Pub/Sub (bot configured without the Workspace
   Add-ons wrapper — events arrive directly from the publisher):
   {"type": "MESSAGE", "message": {...}, "space": {...}}

3. Relay / flat (custom Cloud Run relay that flattens Chat events into
   top-level fields so the bot can run without GCP credentials):
   {"event_type": "MESSAGE", "sender_email": ..., "text": ...,
    "space_name": ..., "thread_name": ..., "message_name": ...}

Previously only format 1 was parsed — format 2 and 3 fell through to
the messagePayload-missing branch and dropped silently. _on_pubsub_message
now delegates to a new _extract_message_payload helper that returns
(message, space, format_name) for any of the three, synthesizing a
Chat-API-shaped message dict for format 3 so downstream code
(_dispatch_message → _build_message_event) reads all three identically.

The relay-format synthesis includes a deterministic ``users/relay-…``
sender name surrogate so dedup keys stay stable across at-least-once
redelivery (Pub/Sub may replay the same logical event).

Tests: 4 new under TestExtractMessagePayload — native format extraction,
non-MESSAGE filtering, relay synthesis assertions, unrecognized
envelope handling. 130 prior tests still pass (134 total).

Patterns adapted from PR NousResearch#17828's NousResearch#14965 baseline by @ArnarValur,
who maintained a Workspace install for several weeks and identified the
parser coverage gap.

Co-Authored-By: Solmundur <168342312+ArnarValur@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…stry

Three reliability/operability improvements pulled from PR NousResearch#14965:

1. Outbound retry with exponential backoff. Wraps `_create_message`'s
   `messages.create().execute()` in `_call_with_retry`, a reusable
   helper that retries 3x on 429/5xx/timeout/connection errors with 1s
   → 8s base + 30% jitter. Permanent errors (4xx other than 429, auth,
   programmer errors) bubble up on the first attempt — no point
   masking misconfiguration with retries.

   Without this wrapper, a single 503 from Google's Chat REST API
   drops the user-visible reply silently.

2. Application Default Credentials fallback. `_load_sa_credentials`
   now tries `google.auth.default()` when no SA JSON is configured,
   so deploys on Cloud Run / GCE / GKE with workload identity work
   without managing key files. Local users keep using the explicit SA
   JSON path; only the unconfigured case changes (used to error,
   now ADCs).

3. Env-var registry entries for `GOOGLE_CHAT_PROJECT_ID`,
   `_SUBSCRIPTION_NAME`, `_SERVICE_ACCOUNT_JSON`, `_ALLOWED_USERS`,
   `_HOME_CHANNEL` in `hermes_cli/config.py`. Makes the env vars
   discoverable in `hermes config` UI under the "messaging" category,
   matching how Slack/Telegram/Mattermost are exposed.

Tests: 6 new (3 retry, 1 retryable-classifier, 2 ADC). 134 prior
tests still pass (140 total).

Patterns adapted from PR NousResearch#17828's NousResearch#14965 baseline by @ArnarValur.

Co-Authored-By: Solmundur <168342312+ArnarValur@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…strip

Two outbound polish improvements that fire on every reply:

1. `format_message`: convert standard Markdown emitted by the LLM to
   Google Chat's formatting dialect before the message hits the wire.
   Without this, **bold**, [text](url), and # headers render as
   literal asterisks/brackets/hashes — Chat's renderer ignores them.
   Conversions:
     **bold**       → *bold*       (Chat's bold uses single asterisks)
     ***x***        → *_x_*        (compound bold-italic)
     [txt](url)     → <url|txt>    (Slack-style anglebracket links)
     # Header       → *Header*     (Chat has no header support)

   Code blocks (fenced AND inline) are protected via placeholder
   substitution so backtick-wrapped content with literal asterisks or
   brackets stays verbatim — matters because the LLM regularly emits
   Python (`x = 2 ** 10`) and shell snippets that would otherwise get
   mangled.

2. Invisible Unicode strip: ZWJ, ZWNJ, ZWS, BOM, LTR/RTL marks, and
   Variation Selectors get removed before send. These render as tofu
   (□) in Chat's restricted font stack, especially in composite emoji
   like 👨‍👩‍👧 (family) and ZWJ flag sequences. Stripping leaves the
   base codepoints intact, so the user sees the closest-renderable
   form instead of square boxes.

Hooked into `send()` BEFORE chunking so the 4000-char limit applies
to the rendered form, not the source markdown. `send_image_file` and
other paths that build their own message bodies are NOT yet covered;
they emit pre-formatted text from internal callers and don't need the
LLM-output normalization. Can extend later if needed.

Tests: 12 new under TestFormatMessage covering all conversions, code
block protection (fenced + inline), edge cases (URLs with parens,
unmatched syntax, mid-line hashes, mixed bold+italic), Unicode
stripping (ZWJ in composite emoji, BOM, bidi marks), empty/None
safety. Two assertions document KNOWN limitations: URLs with parens
truncate at the first `)`, and pure-whitespace input collapses to one
space. 140 prior tests still pass (152 total).

Pattern lifted from PR NousResearch#14965 by @ArnarValur.

Co-Authored-By: Solmundur <168342312+ArnarValur@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Identity convention swap to match Teams' canonical pattern, eliminating
one of our 4 core touches in the process:

Before:
  source.user_id     = "users/{id}"      (Chat resource name)
  source.user_id_alt = sender_email
  + a google_chat-specific block in gateway/run.py:_is_user_authorized
    that injected user_id_alt into the allowlist match set so
    GOOGLE_CHAT_ALLOWED_USERS=email@x.com would match

After:
  source.user_id     = sender_email or sender_name (email when present)
  source.user_id_alt = sender_name (the "users/{id}" resource name)
  + the bridge block in gateway/run.py is REMOVED — the generic
    allowlist match in _is_user_authorized now finds the email
    naturally because it IS the canonical user_id

Why:
- Operators configure GOOGLE_CHAT_ALLOWED_USERS with email addresses
  (the value Google Chat surfaces in its UI), so the email is the
  natural canonical id. Less indirection for operators.
- Removes one of our 4 core touches in gateway/run.py — net diff
  reduction in the upstream PR.
- Matches Teams' identity convention (Teams uses the AAD object ID
  directly as user_id without a side channel).
- Falls back to the resource name when sender has no email (rare —
  bot-to-bot or system events) so allowlists keyed by users/{id}
  still work for that path.

Migration risk: theoretical only. Existing group sessions that hashed
user_id from the resource name would get new session keys after the
swap. In production: zero google_chat group sessions exist (only DMs,
which key off chat_id). The PR has not shipped, so no upstream
operator has stable group-session state to lose.

Tests: 1 updated (TestBuildMessageEvent: user_id == email,
user_id_alt == "users/12345"), 1 renamed + 1 added in
TestAuthorizationEmailMatch (canonical email-match case + fallback
to resource name when no email is available). 152 prior tests still
pass (153 total).

Pattern lifted from PR NousResearch#14965 by @ArnarValur.

Co-Authored-By: Solmundur <168342312+ArnarValur@users.noreply.github.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>