[FEATURE] Warn before reviving a stale session - large cache-expired context re-billed on manual follow-ups AND automatic hook wake-ups

Is your feature request related to a problem?

Two related ways a stale session's large context gets re-billed as uncached input without the user meaning to:

1. Misdirected messages. In the desktop app it's very easy to type into the wrong session: the picker keeps old sessions one click away, several sessions often share near-identical titles (e.g. two "Boot box editor" threads for the same repo), and nothing distinguishes "my active thread from five minutes ago" from "a finished thread from this morning with 150k+ tokens of context". Sending even a one-line follow-up revives the old session's entire context window; with the prompt cache long expired, the whole conversation is re-billed as uncached input - a single misdirected "quick question" costs a large multiple of the same message in the intended session, with no warning and no undo. (Happened to me today: a short follow-up meant for an active thread went to a stale sibling with ~1200 messages of context.)

2. Sessions raising themselves from the dead. Idle sessions keep their hooks/monitors armed. Closing an app or stopping a dev server can fan out wake-up events to every old thread that was watching it, and each one spins up to say the equivalent of "looks like the app stopped, that's fine" - burning its full (often cache-expired) context to produce a shrug. Multiply by a handful of resurrected threads and that's hundreds of thousands of uncached tokens for zero user action at all. (Caveat: I haven't observed this one recently, so it may already be partially mitigated - if so, treat this half as a request to make that guarantee explicit rather than a bug report.)

Describe the solution you'd like

A staleness guard applied to BOTH revival paths - e.g. when a session has been inactive longer than the prompt-cache TTL and its context is large:

• On manual send: an inline notice above the composer ("This session has been idle for 6h; continuing it will re-process ~140k tokens of context") or a one-time confirm on send, ideally with a shortcut to jump to the most recently active session for the same project.
• On automatic wake-ups (hooks, monitors, task notifications): don't silently run the turn. Options: auto-expire/detach watchers when a session goes idle past the TTL; or queue the event as a cheap notification chip the user can choose to act on, instead of a full model turn per resurrected session.

Describe alternatives you've considered

• Visually de-emphasizing stale sessions in the picker (sorting/dimming) - helps, but doesn't catch the case where you're already in the wrong tab, and does nothing for automatic wake-ups.
• Showing an estimated context size next to each session in the picker - useful on its own, but a passive signal.
• User discipline - demonstrably insufficient, and structurally impossible for the self-reviving case :)

Either alternative would be welcome as a smaller step; the send-time warning plus the idle-watcher expiry are the ones that actually prevent the spend.