Stale sessions keep running an old (deleted) binary after an in-CLI update, and idle sessions never trim their heap (~460 MB held for hours)

## Describe the bug

Running the CLI in **multiple terminal tabs** and updating from one of them leaves the others silently running the **old version against a now-deleted binary**, and those abandoned/idle sessions **never trim memory** — one sat at ~460 MB / 23
threads for hours while doing nothing.

### How it actually happens (common workflow)
1. Two (or more) CLI sessions are open, one per terminal tab.
2. In **tab A** I run the in-CLI update command (e.g. `/update`). It replaces the binary on disk and tab A restarts on the new version.
3. **Tab B keeps running the old version.** On Unix, replacing/unlinking an in-use executable is allowed, so tab B's process keeps the **old inode** mapped — `readlink /proc//exe` shows `.../copilot-cli/1.0.11/copilot **(deleted)**`. Nothing tells tab B it is now outdated.
4. Later I forget tab B is even there. It sits **idle** but still resident at ~460 MB, contributing to swap pressure on a 16 GB machine.

This is not a one-off — with several tabs open it happens on nearly every update.

### What this is NOT
To be precise, this is **not** a runaway-CPU bug. `top`/`ps` showed the idle session at ~45% CPU, but that is the **lifetime average** (`utime+stime ÷ elapsed`), inflated by work done earlier while the session was active. Direct sampling of `/proc//stat` over 10 s showed **0% CPU** at idle, with only occasional ~1-core-second bursts minutes apart. A disarmed `timerfd`, 3 inotify watches, and libuv-internal socketpairs (no network peers) all confirm there is no busy loop. The reportable problems are **(a) no stale-version signal after an update and (b) no idle memory trim** — not CPU.

## Affected version
`copilot` 1.0.72 (current), with a lingering 1.0.11 session in another tab.

## Steps to reproduce the behavior
1. Open the CLI in two terminal tabs.
2. Run the in-CLI update from tab A (or `brew upgrade` the cask) so the on-disk binary is replaced.
3. Leave tab B open and idle.
4. Inspect tab B's process (Linux):
- `readlink /proc//exe` -> `.../1.0.11/copilot (deleted)`
- `grep VmRSS /proc//status` -> ~460 MB still resident
- `awk '{print $14+$15}' /proc//stat` sampled over 10 s -> ~0 at idle (confirming the "high CPU" in `top` is a lifetime average, not current).

## What might be nicer (just ideas)
- After an update, it'd be handy if a still-running older session could someho hints that the tab is stale.
- And it'd be nice if a long-idle session didn't sit at hundreds of MB forever, though I appreciate that's easier said than done.

## Some notes on the idle-memory side

Caveat up front: I'm not familiar with the CLI internals, so this is hand-wavey and quite possibly misses context you already have. Just sharing what I bumped into in case it's useful.

From what I understand, for a V8-based runtime GC on its own doesn't tend to hand memory back to the OS — V8 holds freed pages for reuse, and on Linux glibc keeps freed memory in per-arena free lists. So if trimming an idle session were ever worth doing, my rough mental model is that it might involve something like:

- noticing the session has been idle for a while,
- a full GC (`global.gc()` / `--expose-gc`) to clear dead objects — though on its own that often doesn't move RSS much,
- something like V8's `Isolate::LowMemoryNotification()`, which seems more likely to actually release pages (not a userland-JS thing, but the CLI is the embedder so presumably it *could*), and
- on Linux, maybe a `malloc_trim(0)` / `MALLOC_ARENA_MAX` type step, since glibc otherwise seems to sit on the freed arenas.

Very possibly there are good reasons not to bother — a high-but-stable RSS is normal for V8 and isn't itself a leak, and forcing GC has trade-offs. Mostly flagging the ~460 MB idle footprint; the *how* is your call.

## Is this Linux-only?

Not sure, but a rough guess:

- The "GC doesn't lower RSS" bit seems like it'd be all-platform (V8 behavior).
- The "old session keeps running as a *deleted* binary" bit feels Unix-y — Linux/macOS happily let you replace an in-use executable, whereas on Windows a running `.exe` is usually locked, so an in-place update probably fails or defers differently. Either way the stale tab presumably still runs the old code.
- Any allocator-arena step (`malloc_trim`, etc.) would be glibc/Linux-specific; macOS/Windows use different allocators.

So *if* anything here is worth acting on, the stale-version heads-up feels like the cross-platform, lower-risk half; the idle-memory trimming is fuzzier and more platform-dependent. But you'd know far better than me.

## Additional context
- OS: Linux (x86_64), 4 cores / 16 GB, bash, gnome-terminal
- Install: Homebrew cask `copilot-cli`
- Evidence gathered via `/proc//{stat,status,fd,fdinfo}` (strace blocked by `ptrace_scope`). Full sampling transcript available on request.

Reproduce the behavior with two CLI sessions, updating from one and leaving the other idle. Start by checking /proc//exe, /proc//status, and /proc//stat as described; done should establish an actionable stale-version signal and a clear, measured expectation for idle memory behavior.

Written by the indexing model from the issue text.