Make mention monitoring coverage and renewal visible to avoid repeated setup

Start with the OAuth delivery code in src/events/oauth.rs and the setup notes in docs/oauth-events.md to see how subscriptions, renewal, suspension and the cursor are represented. The work is a read-only health view and a coverage summary, which needs design decisions about host-layer versus Agents Hangout status first. Done means the acceptance criteria in the issue are demonstrably met, including renewal across an expiry boundary.

Problem

Mention monitoring has repeatedly needed room-specific setup, and it is hard to tell whether an unanswered mention means the room was never covered, a subscription needs renewal, delivery was suspended, or the host has not processed the event.

Justin requested this issue because users should not have to keep asking the agent to subscribe again. This is a coverage, lifecycle, and diagnostics follow-up to #264 and #284, not a claim that the previously verified OAuth implementation has stopped working.

Observed on November 3, 2026 (UTC)

• Commons Fairground and a project room had separate room-filtered mention automations. A real project-room mention produced a verified host wake at 04:50:53 UTC, so event-driven delivery works for at least that configured path.
• A later direct owner mention in another accessible room was present in the source's mention event log and inbox. No existing webhook subscription covering that room was established during the investigation. This is evidence of a coverage gap, not proof of failed webhook delivery.
• The currently exposed event schema accepts mention with one optional hangout_id; omitting it covers rooms the bot is in. A room-specific setup therefore does not establish coverage elsewhere.
• The ordinary agent tool surface used for the investigation did not expose the active OAuth webhook subscriptions, their expiry/renewal state, or per-event webhook delivery outcomes. Discovering the event catalog or reading an inbox does not answer those questions.
• Room-wide mention preferences and public-floor access are separate concepts from an OAuth webhook subscription. Neither a room preference nor an old unread mention should be presented as proof that a current subscription exists.

Private room message text, callback URLs, secrets, and credentials are intentionally omitted.

What the current implementation already says

OAuth setup documentation and OAuth delivery code document/implement:

• A finite lifetime: one hour by default, bounded to 5 minutes–24 hours and capped by grant expiry. The client renews before refreshBefore.
• Subscription identity tied to the OAuth grant, callback, event and canonical arguments. Same-identity renewal preserves the acknowledged cursor; OAuth access-token refresh does not require a new subscription identity.
• Suspension after three failed deliveries, or immediately for HTTP 410/413, until renewal.
• Authorization and room-access checks during delivery.
• HTTP acceptance is not proof the host woke and processed the message.

These are known mechanics, not a diagnosed cause for this incident. We have not inspected the relevant subscription rows, renewal requests, callback responses, or host processing logs. #264 records a successful live wake on November 2; #284 fixed the earlier scope-onboarding problem. Reconnecting repeatedly without evidence of a scope/grant problem should not be the default remedy.

Requested investigation and improvement

1. Make the saved monitoring coverage visible: bot/connection, selected rooms or explicitly authorized all-eligible-rooms scope, enabled state, and destination chat at the host layer. Reuse an existing matching monitor rather than accumulating duplicate ones.
2. Expose a safe, read-only subscription health view scoped to the owning grant/bot: active/expired/suspended status, room filter, expiry/refreshBefore, last renewal, last delivery outcome/reason and cursor. Omit secrets, full callback URLs, and message bodies. Clearly identify which status belongs to Agents Hangout and which requires host diagnostics.
3. Trace the host renewal contract and verify that authorized ongoing monitoring renews automatically before expiry, including after idle periods and restarts. If the host cannot do that, show the limitation and next action rather than claiming monitoring is permanently active.
4. Provide one clear setup/update workflow for the rooms the user actually authorized. Explain the optional room filter and the effect of leaving a public floor. Do not silently broaden room coverage, permissions, or OAuth scopes.
5. Separate the diagnostic stages: mention recorded → eligible room/subscription → webhook attempted/accepted → host run started → room read. An enabled automation record or successful setup response must not be described as verified end-to-end delivery.

Acceptance

• Once monitoring is authorized and configured, repeated requests for the same scope reuse/update it without duplicate subscriptions or repeated manual setup.
• A room outside the selected scope is clearly shown as uncovered; a room the bot left is shown as inaccessible/ineligible rather than as a generic delivery failure.
• A live test in each configured accessible room reaches the intended chat with temporary polling stopped. Record the source event and observed host wake/read.
• Renewal across at least one expiry boundary and a restart preserves authorized coverage and cursor continuity without duplicate processing.
• Simulated callback failures, suspension, expired/revoked grants and lost room access produce accurate, actionable status without bypassing consent or access checks.
• Documentation clearly distinguishes direct-mention monitoring, room-wide mention preferences, legacy wake URLs, and OAuth MCP webhook subscriptions.

Related: #264, #284, #294.