Reclaim a handed-over key on a curated row uuid instead of reviving it

[MaxGhenis]

Fixes finding L2 from the round-2 independent review of #360 (pre-existing, outside #360's diff).

Stacked on #360. This branch starts at #360's head (f9e0f893), because the enrichment differential it extends lands in #360. Until #360 merges, the diff below includes #360's commits. Once #360 merges, I'll merge the base tip in so only this change remains.

Bug

resolve_uuid's first branch handles a catalog row whose uuid differs from its key's registry binding (the curator-remint path). It planned revive + supersede even when the key had retired after handing its lineage over through a succeeds event. The grammar refuses to revive a consumed key ("revives a consumed lineage — handed-over predecessors are terminal"), so staging rejected the plan before any write. The failure was safe, but the curator got a staging error instead of a valid plan.

The reviewer's repro:

• registry: mint B(US/null)/U1, retire B, E(US/null, economy) succeeds B
• catalog: a geography-free docket row with a hand-edited, unregistered U2
• docket: the entry gains country US, which re-keys the row onto B

Before this PR the builder planned revive B + supersede B→U2, and staging rejected both events.

Fix

• When the key is retired and handed over, the builder now plans a reclaimed event on the row's uuid. That uuid is new to the registry on this path, which the existing ownership check enforces. This matches the branch below it, which already reclaims a handed-over key on a fresh uuid4. Both branches now share _plan_reclaim.
• A reclaim changes no live binding, so it needs no --allow-remint, the same as the existing fresh-uuid reclaim. --check still fails until the reclaim is written ("identities missing from the registry").
• If the row's uuid is already known to the registry, the builder refuses at plan time with a message naming the cause ("handed its lineage over … a reclaimed identity is a NEW series and mints fresh"). Before, the message blamed a supersede. The message also names two remedies: give the row an unregistered uuid, or delete the row so the builder reclaims on a fresh one. A test runs the second remedy.
• The UuidRegistry docstring now lists the reclaim event (it said "five event kinds" and left reclaim out). The backlog doc has a dated entry.

Invariants (stated and tested)

For every registry history the grammar admits, and for every existing docket-only row and entry, at both call sites:

1. Soundness. Every plan build_catalog returns stages under the full grammar, with main's ceremony note on gated events, and the staged registry agrees with the catalog: live bindings and rows are in bijection.
2. Completeness. A retire + succeeds hop is planned exactly when UuidRegistry admits that pair.
3. Refusals. A refusal is a plan-time SystemExit carrying a named diagnostic, and never happens when the grammar admits the hop.
4. No hijack. Without a hop, the row takes its key's binding or a uuid new to the registry, never a uuid another key holds.
5. Handed-over keys are terminal. A retired, consumed key is never revived or superseded. It comes back only through a reclaim on a uuid new to the registry, and its old uuid stays with its successor.

Tests

• test_a_curated_row_uuid_reclaims_a_handed_over_key: the reviewer's exact repro at build_catalog level. The plan is exactly reclaimed B/U2 plus E's gated retire, with no revive and no supersede. It stages, B is live on U2 and no longer consumed, U1 stays with E, and agreement holds.
• test_a_handed_over_key_reclaims_the_row_uuid_through_main: the same move end to end. --check fails first, main then writes exactly the reclaim without --allow-remint, --check passes, and a rerun is byte-idempotent.
• test_a_registered_row_uuid_never_reclaims_a_handed_over_key: the row carries B's own pre-remint uuid. The builder refuses with and without --allow-remint and leaves both artifacts byte-untouched. The named remedy (delete the row) then reclaims on a fresh uuid, and --check passes.
• test_docket_enrichment_is_planned_exactly_when_the_grammar_admits_it (Hypothesis, 400 examples): the docket call-site arm of Let an enriched docket placeholder be enriched again #360's differential, with the same four assertions. It reuses the state-aware _generated_registry. It draws entries with no country, US or GB; rows at any placeholder geography carrying any uuid, including unregistered ones; and rows of another concept that reach the entry only through a curated alias (one draw in five). It also covers reviewer note N2.
  • Steering and measured reach (--hypothesis-show-statistics, seeds 1–3): the handed-over-entry class with an unregistered row uuid (L2) appears in 1.5–4.3% of cases (about 7–23 per run). The same class with a registered uuid appears in 9–10%, and admitted hops in 4.5–6.5% (about 22–35 per run).

Evidence

Check	Result
uv run --locked pytest tests/test_build_series_catalog.py -q	239 passed
uv run --locked python scripts/build_series_catalog.py --check	catalog current: 221 series
uv run --locked ruff check .	All checks passed
Counterfactual: the new tests against the unfixed builder (#360 head), seeds 1–5	The 3 deterministic tests fail. The docket differential fails on 5/5 seeds and shrinks to staging rejecting "revives a consumed lineage" at the docket site.
Reviewer's bounded-exhaustive harness (both call sites), unfixed builder, depth 4	3,416 states, 40,992 builds, 578 divergences, all STAGING-REJECTED hop=False revive=True at the docket site. This reproduces the review.
Same harness on this fix, depth 4	3,416 states, 40,992 builds, 0 divergences
Same harness on this fix, depth 5	17,094 states (188 with a live consumed key), 205,128 builds, 0 divergences
Same harness on this fix, depth 6	58,728 states (2,381 with a live consumed key), 704,736 builds, 0 divergences

The committed ledger never reaches the changed branch: --check output is unchanged, and so is the catalog.

axiom: n/a: catalog builder and registry tooling, with no policy encoding.

🤖 Generated with Claude Code