Parity ledger fails on main, and --refresh-derived cannot repair it #2211

What

Tools/parity_ledger.py fails on main, and the sanctioned repair path cannot run because it validates against the same state that is broken.

FAIL compact baseline drift in test-only-callsite|Packages/WhoopStore

Why the repair path is blocked

--refresh-derived is the reviewed refresh. It writes candidate snapshots, then validates them with parity_ratchet.py against --base, which defaults durably to origin/main. The ratchet refuses:

FAIL derived refresh rejected; snapshots restored
ERROR: Tools/parity_twin_map.json: base authority cannot be reproduced with the current derivation; migration required

That check is:

base_sets = parity_ledger.semantic_authority(base_root)   # base_root = the BASE ref's tree
base_manifest = parity_ledger.authority_manifest(base_sets)
if old_map["authority"] != base_manifest: ... migration required

So it compares the map committed at the base against a fresh derivation of that same base's source, and they disagree. main is internally inconsistent: its checked-in authority no longer reproduces from its own tree.

The deadlock is that --refresh-derived cannot produce the commit that would fix it, because its validation runs against the stale base rather than against the candidate. The other door is shut deliberately:

FAIL --bootstrap-map is for initial authority creation only; use the reviewed refresh workflow for existing authority

Which is correct. Those guards exist so an authority file cannot be rewritten without review, and I am not going to route around them.

What the drift actually is

Fourteen new test-only-callsite findings, all from the same place:

Packages/WhoopStore/Sources/WhoopStore/LiftLogStore.swift  (13)
Packages/WhoopStore/Sources/WhoopStore/LiftMuscle.swift     (1)

e.g. WhoopStore.liftExercises/1 has 3 test callsite(s) and no production callsite.

This is expected and temporary rather than a defect. #2098 landed the lift-log storage deliberately without its consumer, and #2099 is the app that calls this API. Every one of those becomes a production callsite when #2099 lands. Recording it as permanent debt would be recording something we already know is about to stop being true.

Options, none of which I want to pick alone

1. Wait for Lift Log: an on-device gym log book, advanced by a double-tap on the strap #2099, then refresh once. The debt disappears on its own, but main stays red until then and every PR carries a failing check that is not theirs.
2. Teach --refresh-derived to validate the candidate rather than the base when the base is provably unreproducible. That is the real tooling gap and it is not a five-minute change.
3. A reviewed one-off migration commit regenerating the authority, which is what the error's own wording ("migration required") implies exists but which I could not find a supported route to.

The scheduled staleness check from #2142 will presumably start reporting this too, if it is not already.

Not caused by, and does not block

The iOS Coach change in #2207. It touches one SwiftUI view, the ledger is not in its check roster, and this failure reproduces on pristine main with that branch nowhere in sight.