feat(maestro): add [daemon].resume_on_boot policy

Recovery now has a stated policy for sessions whose tmux pane is gone but
whose sidecar survived: dormant (default), auto, or never. auto goes down
the same SessionManager::resume the client's POST takes, so there is one
resume path. never prunes the sidecars the way #163 does for a missing cwd.

The default is dormant because resuming agents unattended seconds after a
reboot is a foot-gun; auto is opted into per host. Recovery logs which
policy ran and how many sessions it acted on.

Refs #167

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/INSTALL.md

@@ -243,6 +243,26 @@ Pick `/tmp` if the daemon must outlive your login session and you can't run
 tmux sockets with it). The env var `MAESTRO_DAEMON_TMUX_TMPDIR` takes
 precedence over the file.
 
+## What happens to sessions after a reboot
+
+A host reboot kills the tmux server, so every session the daemon knew is dead
+while its record on disk survives. What recovery does with those is
+`[daemon].resume_on_boot`:
+
+```toml
+[daemon]
+resume_on_boot = "dormant"   # "dormant" (default) | "auto" | "never"
+```
+
+- `dormant` — the sessions are listed but not running, and you resume the ones
+  you want from the web UI or the TUI.
+- `auto` — the daemon resumes them all itself during startup. Only pick this
+  on a host where restarting every agent unattended is safe: they come back on
+  the flags they were spawned with, with nobody watching.
+- `never` — the records are deleted and a reboot is a clean slate.
+
+See `docs/RESTART.md` for the full contract.
+
 ## What the systemd unit looks like
 
 The wizard writes a *user* unit (`systemctl --user`), since `maestro daemon`

docs/RESTART.md

@@ -96,6 +96,38 @@ neither is something a respawn could fix. The other thing to do with a dormant
 session is dismiss it, which removes the sidecar so the next recovery does not
 bring it back.
 
+## What recovery does with them: `resume_on_boot`
+
+Whether a recovered-but-dead session is left dormant at all is the operator's
+call, per host, via `[daemon].resume_on_boot` (#167):
+
+| value       | what recovery does                                                    |
+| ----------- | --------------------------------------------------------------------- |
+| `"dormant"` | **Default.** Register each one dormant and wait for the operator.      |
+| `"auto"`    | Resume each one during recovery, itself.                               |
+| `"never"`   | Prune the sidecars instead — a reboot is a clean slate.                |
+
+`dormant` is the default because resuming agents unattended is a foot-gun:
+they come back on whatever flags they were spawned with, seconds after a
+reboot, with nobody watching. `auto` exists for hosts where that is known to
+be safe, and it is opted into rather than inherited.
+
+`auto` calls the same `resume` the client's `POST /api/sessions/:id/resume`
+does — same uuid, same sidecar, the preset's `resume_command` — so there is
+one resume path and not two. A session that fails to resume is logged and
+stays dormant; the rest still come back.
+
+`never` prunes the same way #163 does for a missing `cwd`: the sidecar is
+deleted and nothing is registered, so the session is not listed and the next
+recovery does not find it. Whatever worktree it owned is left on disk.
+
+The policy only decides the fate of sessions with no live pane. A session
+tmux still holds is adopted `Running` by the first pass under every policy,
+including `never`.
+
+Recovery logs the policy that ran and the number of sessions it acted on, so
+a host that resumes agents unattended says so in its own journal.
+
 Attaching to a session that has no bridge answers `409 not_attachable`, not
 `404 unknown_session`: the session exists, and a client that cannot tell "gone"
 from "not running" cannot offer the resume.