docs: #489 is fixed and deployed, but criterion 6 is still unmet

The skill said the roll 'does nothing until #489 is merged and redeployed'.
Both have happened, so that sentence now reads as a green light. It is not
one: no roll has bootstrapped a fresh session end to end yet. Say that
plainly, and tell the lead to warn the operator before confirming.

Refs fleetd #489, #480.

.claude/skills/handover/SKILL.md

@@ -164,13 +164,14 @@ fails.
   session.
 - **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 does NOT land today — measured 2026-09-12, fleetd #489.** The first real
-  rollover joined `/clear` and the bootstrap text into one line and Claude Code refused it as
-  `Unknown command: /clearFresh`. The pane was never cleared and no context was lost, so the
-  failure is safe, but the roll does nothing. **Until #489 is merged and the daemon redeployed, use
-  the manual path.** The recovery is the same either way: the file is already written, so the
-  operator starts a session and points it at the file. That is why you write the file before you
-  confirm, and never the other way round.
+- **The bootstrap prompt has never yet landed, and the fix is unproven (fleetd #489).** The first
+  real rollover, on 2026-09-12, joined `/clear` and the bootstrap text into one line and Claude Code
+  refused it as `Unknown command: /clearFresh`. The pane was never cleared and no context was lost,
+  so the failure was safe — the roll simply did nothing. PR #490 fixed the cause and is deployed,
+  but no roll has bootstrapped a fresh session end to end yet. **Assume it may still fail, and tell
+  the operator so before you confirm.** The recovery is the same either way: the file is already
+  written, so the operator starts a session and points it at the file. That is why you write the
+  file before you confirm, and never the other way round.
 
 ## Writing style