feat(remote): show live status for remote sessions

[devsuitup]

Remote sessions currently show no liveness at all. The refresh loop knows only
what the transcript mtime says, which cannot distinguish a session that is
thinking from one waiting for input — neither writes.

The CLI descriptor answers it directly: status (measured value idle, with
statusUpdatedAt), plus pid and procStart to confirm the process is still
that one and not a PID reuse.

Depends on the descriptor read.

Scope: surface the state in the sidebar for remote sessions, and say plainly
when the descriptor is missing — a session whose state is unknown must read as
unknown, never as idle.

[devsuitup]

Correction to this issue's premise, measured today.

status is not a heartbeat. It records the last transition, not the current
moment. On a live production session the field read idle with a
statusUpdatedAt 22 hours old; on a session that had just been interacted
with, the same field was 26 seconds old. A session whose process died would
leave status: "idle" frozen there for ever.

So the status alone cannot answer "is this session alive". It answers "what was
it doing when it last changed state", which is still worth showing — but it must
be paired with a liveness check, and the descriptor carries what that needs:
pid, procStart and pidDomain. Comparing procStart against the process's
own start time is what distinguishes a live session from a dead one whose pid has
been reused.

Consequence for the UI: three states, not two — alive and doing X, alive and
idle, and no longer running. A descriptor with no matching live process must read
as gone, never as idle. And the age of statusUpdatedAt should be visible
wherever the status is, because a state from 22 hours ago and one from 26 seconds
ago do not mean the same thing.

[devsuitup]

Second note, from reviewing #224 — a contract decision this issue has to make
before it builds on the accessor.

getRemoteSessions(alias) returns [] for three different situations that are
not the same thing:

• the host really has no live session;
• the host has never been read yet;
• the last cycle failed (the entry is cleared on failure, deliberately, so a
  dead session is never offered for attach).

They are indistinguishable to the caller. A UI built on [] will show "no
sessions" where it should show "unknown", which is the more honest and the more
useful of the two.

The failure mode is visible: a host that fails every other cycle alternates
between N sessions and zero at each interval, at least 60 s apart, so the badges
blink. A single inventory timeout — the bound is 60 s — clears them for a whole
interval.

Note the asymmetry with the other half of the same cycle: on that same failure
the mirror and the index keep their last good state, so the transcripts stay
visible in the UI while the live sessions drop to zero.

Decide the shape before consuming it — { sessions, at, error }, or null for
unknown against [] for genuinely empty. Whatever the shape, "I could not tell"
must be expressible, and it must reach the UI as its own state rather than
collapsing into "nothing here".