OpenClaw Google Chat spoofing access with allowlist authorized mutable email principal despite sender-ID mismatch

Summary

### Summary Google Chat allowlisting supports matching by sender email in addition to immutable sender resource name (`users/<id>`). This weakens identity binding if a deployment assumes allowlists are strictly keyed by immutable principals.

### Affected Packages / Versions (As of 2026-02-14; based on latest published npm versions) - `openclaw` (npm): `<= 2026.2.13` - `clawdbot` (npm): `<= 2026.1.24-3`

### Details Affected component: - `extensions/googlechat/src/monitor.ts`

The `allowFrom` checks accept: - Immutable sender id (`users/<id>`) - Raw email (`alice@example.com`) for usability

Historically, `users/<email>` was also treated as an email allowlist entry. This is now deprecated because it looks like an immutable ID but is actually a mutable principal.

### Security Triage (2026-02-14) Severity: **Low**

Rationale: - Requests are authenticated as coming from Google Chat (token verification), so this is not a generic unauthenticated spoofing vector. - A realistic exploit generally requires **Google Workspace / IdP administrative control** over identity lifecycle (e.g. reassigning an email address to a different underlying account) to obtain the same email with a different `users/<id>`. - With that level of access, the attacker typically has broader compromise paths.

We still treat it as a valid defense-in-depth report because accepting mutable principals in authorization decisions can increase risk in chained-failure scenarios.

### Remediation / Behavior Changes Goal: preserve usability while reducing footguns. - Raw email allowlists remain supported. - `users/<email>` is deprecated and treated as a **user id**, not as an email allowlist. - Documentation recommends `users/<id>` when strict immutable binding is required.

### Fix Commit(s) - `c8424bf29a921e25663b29f308640b3d91a49432` (PR #16243)

Thanks @vincentkoc for reporting.