fix(ca): an agent with a pane open is not still "waking"

[codyde]

Problem

Create a new cloud agent, land in its session, and the tree still calls it "waking" while you're typing into it.

The row renders the platform's raw status, and sorted_agents already spells out the vocabulary — "running first, waking next, sleeping last" — where the middle rank is literally status == "starting".

That status lags routability by design. #1098 established the gap: the platform routes a shell as soon as the container exists, while RUNNING additionally waits on route publication, a projection hop, and a poll interval. The launcher stopped gating attach on it and started probing the route instead — but the tree kept rendering the value the CLI had already decided not to trust.

Fix

An attached, unfinished pane is direct evidence the agent is up: there's a shell running on it. Believe the pane over the projection.

Where	Change
displayed_status	Row status and note read running once a pane is open.
sorted_agents	Ranks on the displayed status, so the row doesn't sit in the waking band while reading running.
attach_session	Clears a settled wake op and its watch — a pane opening proves the wake landed, and it stops the 1.5s watch tick polling that environment for up to WAKE_PATIENCE about an agent already taking keystrokes.

Scoped to starting only. A pane can outlive what it's attached to, and sleeping/crashed/failed/deleting alongside a live pane is news the user needs, not latency to paper over. Sleep and delete ops are untouched — neither is proven by an attach.

Testing

1126 pass, 0 clippy errors. Four new tests:

• an agent with a pane open reads running (fails with starting if the override is removed — verified)
• every non-starting status survives an attached pane
• an ended pane stops counting as evidence
• an in-flight sleep isn't settled by an attach

Why the override is bounded

An unbounded "pane open ⇒ not starting" rule would hide the case that prompted this: an agent that stays starting, routes SSH fine, and has to be deleted. Painting that green removes the only signal the user has.

So the override only covers the window the lag actually lives in. Benchmarked with 10 × railway code --claude --new (agents cleaned up after):

metric	min	median	max
create returns	1.9s	3.6s	8.9s
status → RUNNING	5.3s	8.4s	14.2s
end-to-end (create → Claude's first reply)	10.3s	13.5s	19.3s

Status reached RUNNING before the harness answered in all 10 runs, worst case 14.2s from create — and a pane opens partway into that. STARTING_GRACE is 45s: generously clear of a slow-but-healthy boot, but bounded, so an agent still starting past it goes back to reporting what the platform says.

The decision is a pure function of (status, pane age), so the boundary is unit-tested directly rather than through a fabricated Session clock.

🤖 Generated with Claude Code