feat: the fleet board contract — clients can finally see the conductor (P5.0)

[saucam]

Why

The conductor has been shipped and invisible. P0–P4 gave it cross-workspace session resolution (21.6% → 73.0% P@1), a durable crash-safe dispatch queue, delegated worker identities and compressed digests — and by deliberate design it added zero client↔daemon wire types, rendering as an ordinary session whose fleet_* calls are tool cards.

That is enough to chat with it. It is not enough to see the fleet: the task board, worker lifecycle, blocked tasks and audit trail live only in daemon SQLite. conductor-design.md said it plainly — "designed, not built — the only front door today is codeoid attach conductor in a terminal."

This is the one additive read+subscribe surface that closes the gap (conductor-frontends-design.md §11). It adds no dispatch semantics — every field it exposes is already held by the daemon.

fleet.subscribe    -> fleet.snapshot.result, then streamed fleet.update
fleet.unsubscribe

The scope question

Gated on a new fleet:read. Deliberately not session:read/session:dispatch — those are ZeroID scopes delegated to the conductor's own agent identity to gate its fleet_* MCP tools; this gates a human's client reading the board over the wire. Also separate from session:list, because the board exposes orchestration internals (what was dispatched, what failed, what it cost) beyond the session enumeration a watcher already gets.

Three decisions the spec sketch didn't settle

• fleet.unsubscribe added. Without it a client that navigates away could only stop the stream by dropping its socket.
• One board-change hook, not fourteen. DispatcherHost.onBoardChange fires once per entry path (enqueue, group enqueue, end of tick) rather than at each of the ~14 store mutations. Every mutation happens inside one of those paths, so coverage is complete by construction — a mutation added inside the tick later cannot be missed.
• Deltas are exactly-once via a compound watermark. updated_at is millisecond-granular and one tick routinely settles several tasks in the same millisecond, leaving a single cursor only bad options: > drops every task sharing the boundary millisecond, >= repeats them forever. The watermark carries taskUpdatedAt plus the ids already delivered at exactly that millisecond — inclusive query (no drops), id set (no repeats). I found this because a test I wrote asserted the stronger property and failed.

Not on the wire, on purpose

The dispatch prompt and worker workdir. The board draws lifecycle; the prompt is the one task field that would carry arbitrary user text to every subscribed client. A test asserts it never appears. dependsOn is on the wire type but never populated, exactly as §11 specifies, so typed fan-in edges stay a non-breaking add.

Companion PR

highflame-ai/codeoid-ui mirrors this and adds the SessionInfo.role field that crate never modelled — the prerequisite §10 flagged, and the reason the TUI couldn't badge a conductor. Every new Rust enum carries #[serde(other)] so a newer daemon degrades to an unrendered node rather than failing the whole board's deserialization. Its wire tests parse JSON captured from this running daemon, not hand-written fixtures — for a hand-maintained mirror, a fixture written from the same assumption as the code proves nothing.

Verification

• 2310 daemon tests pass (13 new in src/tests/fleet-board.test.ts), 409 web, 7 Rust suites
• lint / typecheck / check:versions clean both sides; cargo fmt + clippy clean
• New tests cover tenancy isolation on both snapshot and delta, scope enforcement, prompt confidentiality, watermark advance, unsubscribe, disconnect reaping, and the no-subscriber path (the dispatcher signals on every tick, including on a daemon nobody is watching)

Two pre-existing exhaustiveness guards caught the additions before I did — the DaemonMessage switch test and the client-message fixture map. Both updated.

No client draws the board yet — that's P5.1–P5.4.