Expose per-client last-activity (latest-interaction client) via the API

[vaultboy001]

The why. I use herdr from three devices — laptop (--remote), phone over ssh, local terminal — with a coding agent inside the session. The agent has no way to tell which device I'm actually working from, so it can't avoid doing file operations on the wrong machine. Every signal outside herdr (socket byte counters, utmp idle) is a heuristic that misleads.

What already exists. The server tracks a monotonic last_activity stamp per client (it picks the fallback foreground client with it). Interaction events (key/text/mouse/paste/focus) bump it; protocol traffic never does. It's exactly the answer — it's just not exposed.

The ask. Surface it: e.g. client.list API or herdr status clients, returning per-client last_activity and the connection's peer pid (getsockopt LOCAL_PEERPID, for mapping to a device). ~20 lines.

Done on a fork. Implemented, unit-tested, and verified against a real attach (branch feat/client-list in vaultboy001/herdr). Not opening a PR per the contribution policy — happy to adjust the shape or hand over details.

[MPavleski]

Another use case for this: a long-running program inside an existing tab needs to know whether the most recent interaction with that tab came from a local client or a remote SSH/mosh client.

For example, I start Herdr and the program locally on my desktop, then later attach over SSH or mosh and continue using the same tab without restarting anything. The program still inherits the original DISPLAY/WAYLAND_DISPLAY and SSH_* environment, so those variables cannot describe the current interaction source. A query using its tab/pane identity would be useful.

The important distinction is per-tab/pane attribution, rather than just the latest active client across the whole server. A local client may remain attached, or interact with another tab, while I use this tab remotely. Both clients may also view the same tab.

The question I want to answer is: Which client last delivered interactive input to this tab/pane, and was that attachment local, SSH, mosh, or unknown? Viewing, focus changes, resize events and background API traffic should be distinguishable from input to the program.

This would help programs choose an appropriate interaction or notification UI after reattachment. A best-effort routing hint is sufficient; it need not prove physical presence. Explicit unknown/no-input-yet state and whether the last input source is still attached would prevent stale information from being mistaken for current availability.