handover skill: BOOTSTRAP_NEVER_SENT, and relaunchReadySeconds bounds three waits

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

.claude/skills/handover/SKILL.md

@@ -189,8 +189,9 @@ If the first number has grown past 20, somebody has rolled under the restart pat
 should be replaced with what they measured.
 
 **Three separate timeouts bound a roll.** `leadRollover.relaunchReadySeconds` (default 45,
-`FleetConfig.java:1483`) bounds **each** of two waits that run after the relaunch, so the worst case
-there is about twice that number, not 45 seconds in total. A third bound gives your old pane 10
+`FleetConfig.java:1483`) bounds **each** of three waits that run after the relaunch, so the worst
+case there is about three times that number, not 45 seconds in total. The third wait retries
+`bootstrapText` while herdr answers `agent_not_ready`. A separate bound gives your old pane 10
 seconds to die (`LeadRollover.PANE_DEATH_TIMEOUT_SECONDS`).
 
 `fleet_handover{action: "status", token}` answers with one of these:
@@ -204,6 +205,7 @@ seconds to die (`LeadRollover.PANE_DEATH_TIMEOUT_SECONDS`).
 | `RELAUNCH_FAILED` | launching the fresh pane failed |
 | `RELAUNCH_NEVER_READY` | the fresh pane never became ready within `relaunchReadySeconds` |
 | `RELAUNCH_NOT_RECOGNISED` | the fresh terminal never resolved as a lead |
+| `BOOTSTRAP_NEVER_SENT` | the fresh pane was ready, but herdr refused `bootstrapText` with `agent_not_ready` for the whole bound, so the successor never learned where the handover file is |
 | `FAILED` | the roll threw; `runRollover`'s catch records this rather than leaving it stuck |
 
 Only `TURN_NEVER_SETTLED` guarantees your context is intact. The other failures can leave you