Bug

When a session is reset via /new, performGatewaySessionReset → ensureSessionRuntimeCleanup calls clearSessionQueues() to purge followup/command lane queues, but does not drain the process-global system-events Map (keyed by sessionKey).

Because sessionKey is preserved across /new, any system events enqueued before the reset (e.g., exec failure notifications from maybeNotifyOnExit) survive and get drained by rebuildPromptBodies into the first user message of the fresh session as System (untrusted): ... prefixed text.

Impact

• Fresh sessions can start with stale, unrelated system event text injected into the first user message
• Exec failure events may contain file paths or truncated command output, creating unintended context leakage across session boundaries
• Affects all channels, not Telegram-specific

Reproduction

1. Trigger an exec failure in an active session (any command that exits non-zero)
2. Run /new
3. Send any message — inspect the first user row in the session JSONL
4. The stale exec failure text appears as a System (untrusted): prefix on the first user message

Proposed Fix

In ensureSessionRuntimeCleanup, after clearSessionQueues([...queueKeys]), loop-drain drainSystemEventEntries(key) for each queue key. ~5 lines, no function rewrite. This is symmetric with the existing followup/command queue purge.

Optional Hardening (separate concern)

Consider redacting or truncating raw exec output in maybeNotifyOnExit before enqueuing as system events, since even within a single session, failed commands can surface sensitive paths/content in model context.