Review follow-up for #15: don't strand a raw terminal, and gate passive at the constructor

[iksteen]

Review follow-up for iksteen#15 — one commit on top of your two, so you can take it, take part of it, or ignore it. Nothing is merged on my side.

1. A permanent hub failure could leave the terminal in raw mode

client::run bails out on a 403 (rejected key) and a 426 (wire skew). That was safe only because the source could not exist yet — the gate you're bypassing is what guaranteed it. With eager_start the command is already running in raw mode when those fire, and nothing restores it: there is no Drop for RawMode, and the only raw.restore() is the child-exit path, which never runs here. A caller that exits on the error — the CLI does — leaves a terminal with no echo and no line editing.

The fix announces through the notifier's existing outage pause before propagating, so the terminal comes back cooked with the reason on screen. A passive source is deliberately left alone, same contract as an ordinary outage.

Worth noting this was reachable before your PR too: a mid-session reconnect that gets 403'd after the hub's --allow changes hits the same bail! with a live backend. eager_start just moves it from obscure to likely.

I did not make 403/426 retryable — RECONNECT_BACKOFF is 500ms and the hub logs rejections for fail2ban, so a client retrying a bad key twice a second is exactly what that log is for.

2. passive can stop at the constructor

Notifier is the only producer of Msg::HubDown/HubUp, and the two arms you guard are the only consumers. Not installing it makes them unreachable by construction instead of by two guards that have to stay symmetric, and NoopSinkStatus already exists for this. screen_thread goes back to 10 arguments.

The flags themselves stay exactly where you put them — eager_start on the transport, passive on pty::start. They're orthogonal: an external_source() producer already gets NoopSinkStatus and wants only the first, and a PTY embedder may well want passive with the hub-gated start.

3. Docs

docs/library-api.md still said the factory runs only after the upgrade succeeds. Documented eager_start and its pairing with passive, and noted on HubState::live why it's public.

---

fmt, clippy -D warnings, cargo test --workspace (191 passed), and the five subset feature builds are all green. One test added for the new path.

🤖 Generated with Claude Code