Ambient group mode runs blind: room-event turns get no room context, over-reply, and leak notices

Current behavior

With messages.groupChat.unmentionedInbound: "room_event" (ambient mode), the agent decides whether to chime in on every unmentioned group message — but the context pipeline that should inform that decision is broken end-to-end. Production analysis of a real Telegram deployment (48h window):

• 74% of room-event turns contained zero conversation context — the model judged isolated fragments ("Tell", "What") with no surrounding messages and guessed it was being addressed (~11% chime rate per ambient turn, compounding to a visible reply every ~6 group messages once reply-to-bot amplification is counted).
• The per-group pending-history window stopped reaching prompts entirely after June 18 (0 occurrences of either history marker in 12 days of transcripts; 137 before).

Root causes (all verified against source)

1. Default-off regression from Control Telegram group history context #89547 (32af1c06972, shipped v2026.6.10): includeGroupHistoryContext defaults to "mention-only", and includesRecentTelegramGroupHistoryContext() gates BOTH delivery paths of the pending window (extensions/telegram/src/bot-message-context.session.ts combinedBody fold + inboundHistory) to "recent". Ambient mode's premise is context from unmentioned messages; the default strips exactly that. The PR's tests never exercise ambient mode with the default config.
2. Destructive wipe lifecycle (predates Control Telegram group history context #89547): every non-room-event turn wipes the whole window at dispatch end (bot-message-dispatch.ts: shouldClearGroupHistory = !isRoomEvent || ...), and delivering room events wipe it too. The semantics come from the legacy "messages since your last reply" model where cleared messages had been folded into a persisted session turn — but room events are deliberately not session-persisted, so the wipe destroys the only copy.
3. One-sided recording: only room_event messages are recorded; user_request messages and the bot's own outbound sends never enter the window — the model cannot see the conversation happening with it, nor its own recent posts to self-regulate frequency.
4. Act-inviting prompt posture: the room-event envelope's only directive is "Decide whether to act"; the embedded delivery hint says "Use the message tool to send the final user-visible answer" (presupposing an answer) and falsely claims status updates are shown; the strongest "Be extremely selective" guidance ships only in the legacy NO_REPLY mode; the always-on group intro instructs "Address the specific sender"; the reply-etiquette bullet is Discord-only.
5. Suppression leaks: fast-mode auto notices (dispatch + followup paths), verbose 🛠️ tool summaries on queued room-event followups, followup error/compaction notices, and queue-overflow summaries that strip the room_event kind (inviting a visible reply to messages nobody addressed to the bot).

Fix (three PRs)

1. fix(telegram): keep group history always on — removes includeGroupHistoryContext entirely (maintainer decision: revert what Control Telegram group history context #89547 added; historyLimit, including 0, remains the only knob), converts the window to a rolling window with non-destructive last-self-entry watermark selection, records all group inbound plus the bot's own sends, adds an openclaw doctor --fix migration for the retired key ("none" maps to historyLimit: 0 to preserve privacy intent).
2. fix(auto-reply): default room events to silence — default-silent room-event envelope, truthful room-event delivery hint, selectivity guidance extended to ambient mode, lurk-aware always-on intro, group etiquette generalized beyond Discord.
3. fix(auto-reply): suppress room-event notice leaks — closes the five delivery bypasses listed above.

Deliberately deferred: a unified per-room "participation mode" resolver (single owner for wake/classification/history/delivery coherence) — additive, tracked separately after these land.