Fleet Deck

Fixed

• A card stranded mid-resume is released instead of reading reviving… forever. A revive (or adopt) marks its card as an in-flight resume and waits for the new pane's first hook to move it on. If that hook never arrived — the daemon was restarted during the launch, or the pane died the instant it was exec'd — the card kept the transient note permanently, the board offered no way to try again, and the only recovery was editing fleetd.db by hand. Neither the spawn-row reconciler nor the tombstone path could fix it: both skip a session that already has ended_at, which every resume target has by definition. Such a card is now released back to offline and revivable, at daemon boot and on the liveness tick, so a wedge created at runtime clears without a restart.

  The check is a proof, not a timeout: a resume inserts its provisional spawn row before it flips the card, so a card presenting as in-flight with no spawn row in provisioning|spawning|stalled|live cannot be a resume that is merely slow. At boot the heal deliberately runs after row reconciliation, because a row the previous daemon left spawning would otherwise read as a live resume.

How this was found: claude was missing from the daemon's PATH, so every revived pane died instantly (env: 'claude': No such file or directory, status 127) and two cards stranded at reviving… with no affordance to retry.

Operator note (not a code change): if you run the daemon as a service, its PATH must be able to resolve claude and the same tmux that owns the fleet session. A service manager's default PATH typically resolves neither. For the systemd unit that means setting PATH= in ~/.fleetdeck/service.env.

Full changelog: https://github.com/lacion/fleet-deck/compare/v0.19.0...v0.19.1