#2712 gatorwalk-factory: claim can wedge a ticket on a reservation whose factory no longer loads (GW-18 follow-ups)

Follow-up to #2686 (GW-18, merged in swamp-extensions PR 365). Findings from the verify-reviews runs on that PR, left for this issue. All code is in gatorwalk-factory/extensions/models/_lib/claim.ts and _lib/tracker_methods.ts (unpublished; read gatorwalk-factory/README.md and DESIGN.md, "Start from a ticket", first).

Medium: a reservation under an unusable holder can never be replaced

claim writes the ticket index record (ticket-) before the work item starts. If the start never runs, later claims either hand back the same start command for the reserved holder or, when a different lifecycle is passed, refuse with "start it with ''". If that holder is deleted, renamed or becomes an invalid lifecycle before the start runs, the printed start fails and every other holder is refused, so the ticket is stuck until someone deletes the index record by hand.

Repro: claim T1 with lifecycle=team; delete the team definition; run the printed start (fails); claim T1 with lifecycle=other, which is refused.

Suggested fix: when the reserved key has no run and a different lifecycle is given, check whether the reserved holder still loads (loadHolderLifecycle); if it does not, re-reserve under the new holder (new key, or the same key), and say so. Or an explicit override input. Add a unit test for the case and update DESIGN "Start from a ticket".

Low (take or reject each)

1. Unquoted key in the printed start command: startCommand shell-quotes the holder and externalRefs but not the key. Keys are generated from a safe alphabet, so this only matters for a hand-edited index record; quoting it is one line.
2. A lifecycle input that differs from the holder of an already-active work item is silently ignored (a reservation with no run refuses the same mismatch). Either mention the holder in the "already started" message or refuse consistently.
3. If the snapshot write fails after the index record was written, claim reports failure even though the reservation exists (the next claim recovers it). Consider logging a snapshot failure instead of throwing, as the metrics write does.
4. The previous list in the index record grows without bound across finished-and-reclaimed work items. Probably accept it and say so next to the Retention note in DESIGN, or cap it.