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/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.