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.

索引モデルが issue の本文から書いたものです。