Fleet connection state machine + status bar + reconnect command

[aarontrowbridge]

Important

Scope. Slice 4 of Managed Fleet (#283 — read it first). The connection state machine — connecting → connected → reconnecting → unreachable, plus fallback-active and rejoining (entered/exited by slices 7's flows) — rendered as a status-bar item ("Fleet: <state>") with a manual reconnect command. This is the fleet's visibility surface: every state the 2026-08-07 incident hid is named and shown.

Acceptance Criteria

1. Every tunnel/attach event drives the documented transition; killing the tunnel produces reconnecting (not silent deadness) within the backoff tick, and recovery lands in connected with no window reload.
2. unreachable offers the two repairs inline: retry, or enter Local fallback (slice 7 wires the latter; here the affordance + event exist).
3. The status-bar item always reflects the machine's actual mode and state — standalone panels show no fleet item at all.
4. A manual "Reconnect to Fleet" command drives the machine from any state back through connecting.

Testing Decisions

State-machine unit tests (event-driven, fake timers: every documented transition + the illegal ones asserted absent); status-bar rendering tests reusing the existing status_bar test surface; reconnect command test. Reuse-first against the extension's status_bar tests; new surface only for the machine itself.

Key Decisions & Constraints

• The state machine is the single writer of fleet status; UI, Doctor (slice 5), and fallback flows (slice 7) consume its events rather than probing independently.
• States are user-visible vocabulary: names in the status bar match the glossary (CONTEXT.md).
• Parent constraints apply; slice-local: no state may require a window reload to leave.

Source

Part of #283 · Design: docs/adr/0005-managed-fleet.md (PR #282) · Blocked by #286 (its events come from the tunnel + attach path).