feat: add window_title to shpool list --json

[GeoffChurch]

Issue Link

Discussion #440

AI Policy Ack

ack

Drafted with vibes, edited and tested with meat

This PR was:

• mostly or completely vibe coded
• mostly or completely meat coded
• bit of both

Description

Adds window_title to the output of shpool list --json:

{
  "sessions": [
    {
      "name": "djt-miner",
      "started_at_unix_ms": 1790885744638,
      "last_connected_at_unix_ms": 1791385820043,
      "last_disconnected_at_unix_ms": 1791383990390,
      "status": "Disconnected",
      "shell_pid": 51725,
      "attachments": [],
      "window_title": "Coins mined: 23.203 ($0.00032). Level: patriot"
    }
  ]
}

The use case is letting downstream tools show the user the window titles of their sessions. Many processes (shells, coding assistants, etc) send status information to the window title, which is traditionally visible in a terminal window/tab but in shpool is inaccessible without attaching to the session.

This change exposes the current title through shpool list --json without attaching.

[ethanpailes]

I think you'll need to pull in shpool-vterm 0.2.7 (shell-pool/shpool-vterm#12)

[ethanpailes]

I'd like to take a different approach to avoid double-storing the same data.

[ethanpailes]

It seems a bit strange to store the title persistantly in the session struct. I would think it would be better to always dynamically fetch it from the term impl.

[ethanpailes]

same thing, I don't think we should reify this in a data structure like this

[ethanpailes]

I think the right approach would be to have this shell to client channel expose another channel rpc called fetch_metadata or something like that. For now we would just return the title and session name, but we could extend it with other things in the future. That would prevent having to think about invalidation logic. The list handler could issue all the requests up front so all the shell threads could work in paralell and then gather the answers in a second phase.