No way to see which routine sessions are still alive and holding resources

## Summary

A routine run whose session has exited and one whose session is still resident on a `remote-control` bridge look identical in the UI. Both display as succeeded. Nothing indicates a process is still alive.

Fourteen sessions accumulated on my bridge over ten days, one per routine firing, none exiting after their run completed (#93549): ~1.9 GB RSS combined, each ticking 0.5–2% CPU while idle. The only two signals I found were the `claude remote-control` terminal's attached-session count and `ps` on the host, neither of which is intuitively the surface to monitor.

Leaked sessions hold the bridge's concurrent-session capacity. When it fills, the next firing cannot spawn and a scheduled job silently stops running, with no warning surface in front of it and no failed run to show for it afterwards. Being unable to *find* a completed routine is an inconvenience; being unable to tell that something is still consuming resources means the problem stays invisible until it breaks something.

## Request

1. Track session liveness server-side, so a session whose process has exited stops reporting `active`.
2. Make a live session visibly distinct from a finished one wherever runs or sessions are listed.
3. Surface a per-environment count of live sessions against capacity. That number predicts the outage, and the bridge terminal already prints it locally.

## There is no liveness signal in the API either

`GET /v1/code/sessions?trigger_id=…` returns `status` and `worker_status`. Neither tracks whether the process is alive:

| Session state | `status` | `worker_status` | process |
|---|---|---|---|
| Mid-turn | `active` | `running` | alive |
| Run completed, process leaked | `active` | `idle` | alive |
| `SIGTERM`ed hours earlier | `active` | `idle` | **dead** |
| Archived | `archived` | `idle` | dead |

`worker_status` only separates "running a turn" from "not"; `status` only separates archived from not. A leaked session and one killed hours ago are indistinguishable.

Ten sessions I `SIGTERM`ed at 01:00 still reported `active` at 02:45, processes long gone. So the server's own record of which sessions are alive is wrong, and no client could render the truth from it today.

## Contributing factor

Fired one-shot routines are hidden from the routines list by default, and the filter menu (All / Active / Paused / Auto-Disabled / On Hold) does not reach them: a fired one-shot is `enabled: false` with `ended_reason: "run_once_fired"`, yet does not appear under "Auto-Disabled", and "All" excludes it. The control that reveals it is "include completed", under **sort**. So a leaked one-shot session is hidden twice over.

## Environment

Claude Code 2.1.247, Claude Desktop app, macOS (Apple Silicon), cloud routines targeting a `kind: bridge` environment.

## Related

- #93549: routine sessions are never sent `end_session` on completion, the leak this defect makes invisible
- #72308, #68626, #73631: session and process leaks on other spawners
- #74682: auto-archive routine sessions after completion
- #86115: paused scheduled tasks disappearing from the Routines list

Start with GET /v1/code/sessions?trigger_id=… and the sessions and routines list surfaces described in the issue. Compare the existing status and worker_status values with process liveness, then trace how completed one-shot routines are filtered. Done means dead sessions no longer report active, live and finished sessions are distinct, and each environment shows live sessions against capacity.

Written by the indexing model from the issue text.