fleetd #726: tell the handover skill which rollover behaviour is live

Unit 2 replaces the /clear continuation with a real process restart, so every
paragraph in the skill that describes /clear goes false the moment the new jar
is deployed. The code is not merged yet, and a merge is not a deployment, so
rewriting those paragraphs now would hand a lead doing a handover tonight a
document that does not match the daemon it is talking to.

Add a dated note instead. It states that the /clear text stays accurate while
the old jar runs, and gives a test a lead can apply with no shell: the
fleet_handover tool description is served by the running daemon, so if it still
says "clear your pane", the old behaviour is live. It also names the two things
that change, including the one that doubles as a second indicator -- the
"never observed as WORKING after 8 consecutive IDLE/DONE polls" warning cannot
appear once the wait that logs it is deleted. The note names the condition for
deleting itself.

Re-measure the roll evidence while here. The skill recorded four
"lead-rollover: rolled" lines from 2026-09-22; the log now holds 20, against a
control of 86 "lead-rollover:" lines, and "Unknown command" still returns 0.
Add the elapsed spread (median 16507 ms, max 48261 ms, two above 45000 ms) with
the caveat that it times the whole roll and is dominated by the wait for the
calling turn to end, so a slow roll is not a failed one.

Markdown only, no code touched, so no build was run.

.claude/skills/handover/SKILL.md

@@ -159,6 +159,29 @@ fails.
 
 `{action: "cancel", token}` drops a pending request without rolling.
 
+**A change is coming: the roll will restart the process instead of sending `/clear` (fleetd #726
+unit 2, written 2026-10-04).**
+
+Today a roll types `/clear` into your pane. Your `claude` process keeps running, so a newer CLI on
+disk is never loaded. Unit 2 replaces that: the daemon ends the old pane, launches a fresh one,
+waits for the new terminal to be recognised as a lead, and only then sends the bootstrap text.
+
+**Everything below about `/clear` is accurate while the old jar is running.** Unit 2 was not merged
+when this note was written, and a merge is not a deployment.
+
+**How to tell which one is live: read your own tool list.** If `fleet_handover`'s description says
+it will "clear your pane", the daemon is serving the old behaviour. If it names a restart, the new
+behaviour is live. The description comes from the running daemon, so it cannot disagree with the
+code that is actually loaded.
+
+Two things change for you once it is live. The `status` outcomes are different: three new failures
+replace the `/clear` ones. And the "never observed as WORKING after 8 consecutive IDLE/DONE polls"
+warning described below can no longer appear, because that wait is deleted — so if you still see
+it, the old jar is running. `TURN_NEVER_SETTLED` does not change, and still means nothing was
+touched.
+
+**Delete this note and rewrite the `/clear` paragraphs once the new jar is live.**
+
 **Things that will surprise you:**
 
 - **`accepted` does not mean your pane has been cleared.** It means every gate passed and the roll
@@ -200,13 +223,18 @@ fails.
 
 - **The roll can still refuse after `confirm` returns**, and by then there is no caller to tell.
   Those outcomes are logged only, as `lead-rollover:` lines in the daemon log.
-- **The bootstrap prompt works end to end. Measured 2026-09-22.** This used to say the fix was
-  unproven (fleetd #489) and told you to expect a failure. That is no longer true. The daemon log
-  now holds four `lead-rollover: rolled` lines, and three of them ran on 2026-09-22 at 10:01:43,
-  10:38:28 and 11:15:47. Each one cleared the old lead and started a fresh session against the
-  handover file, with the configured `bootstrapText` arriving as its first message. No context was
-  lost. The old `Unknown command: /clearFresh` failure from 2026-09-12 does not appear in the log
-  at all. Re-measure both numbers with:
+- **The bootstrap prompt works end to end. Measured 2026-09-22, re-measured 2026-10-04.** This used
+  to say the fix was unproven (fleetd #489) and told you to expect a failure. That is no longer
+  true. On 2026-09-22 the daemon log held four `lead-rollover: rolled` lines. On 2026-10-04 it holds
+  **20**, against a control of 86 `lead-rollover:` lines. Each roll cleared the old lead and started
+  a fresh session against the handover file, with the configured `bootstrapText` arriving as its
+  first message. No context was lost. The old `Unknown command: /clearFresh` failure from 2026-09-12
+  does not appear in the log at all.
+
+  19 of the 20 carry an `elapsedMs`: median 16507 ms, maximum 48261 ms, and two above 45000 ms. That
+  figure times the **whole** roll, and the wait for your own turn to end dominates it, so do not
+  read it as the cost of the clear. Expect a roll to take tens of seconds, and do not treat a slow
+  one as a failed one. Re-measure all of these with:
 
   ```bash
   grep -c "lead-rollover: rolled" fleetd/fleetd.out   # successful rolls