fix(maestro): guard resume against kill and second resume

The respawn runs with the session map unlocked, so two takes of the
lock straddle it. A kill landing in that window deleted the sidecar
before resume wrote it back, leaving a file for a session that was
gone — the next recovery registered it as a dormant ghost. Resume now
deletes the sidecar in the branch where it finds its own record gone.

Two resumes both passed the `Running` check for the same reason. The
record is marked in-flight under the first lock, so the second request
is refused with `already_running` instead of losing a race for the
FIFO and reporting a tmux failure. Every path out of resume clears the
marker.

Both races are driven deterministically in the tests: the manager's
tmux spawn is parked mid-resume while the racing kill or resume runs.

Closes #175

docs/RESTART.md

@@ -98,7 +98,13 @@ conversation id is respawned on the command it was created with. `Session::comma
 always keeps that original command, so a second resume resolves the same preset.
 Resume is refused with `409` for a session that is already running
 (`already_running`) and for one whose `cwd` has disappeared (`cwd_missing`) —
-neither is something a respawn could fix. The other thing to do with a dormant
+neither is something a respawn could fix. A session with a resume already in
+flight is refused as `already_running` too (#175): the respawn happens with
+the session map unlocked, so the record is marked in-flight before it starts
+and the second request is answered on that state rather than on its tmux spawn
+colliding with the first one's. A resume that loses a race with a kill takes
+its own sidecar back off disk, so the killed session does not return as a
+dormant ghost on the next recovery. 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.