F0: stop claim-id serial drift — resolve ids by paging the primary index

[lucca65]

Claim rows were landing on DB serials instead of their chain ids, so the Elm app signed verifyclaim(db_id) against a claim that either did not exist or belonged to someone else.

Root cause

claimaction does not carry the generated id, so resolveClaimId read it back off chain. That read used the byaction secondary index — and on prod nodeos (v2.0.7) the get_table_rows walk is time-budgeted, so it stops early and sets more: true. The old code threw on more, and the caller caught the throw and fell back to a serial.

Measured against prod on 2026-08-07:

• the identical bounded byaction query returned 31, 35, 38, 51, 60, 67, 79 rows on seven consecutive calls, always more: true — the count tracks page-cache warmth, so it is not even deterministic. Once warm the same query returned all 115 rows with more: false.
• an unbounded read with limit: 5000 returned 27 rows, more: true.

So more is an honest truncation signal. An earlier revision of this PR read it as spurious and replaced the guard with "did we hit limit" — that would have accepted a truncated set, and since the target claim is the newest one for its pair (exactly what truncation drops first), resolution would return undefined and the claim would be skipped and never inserted. That trades silent wrong ids for silently dropped claims.

Fix

Resolve against the primary index, walking forward from a watermark (the highest claim id already recorded) and paging on next_key until more is false. Claim ids come from one global counter (get_available_id("claims")) and blocks are processed in order, so the claim a claimaction created is the first chain claim for its (action, claimer) above that watermark.

Truncation then costs an extra request instead of corrupting the answer, and a claim skipped earlier sits below the watermark once anything later is recorded, so its id can never be handed out twice. A secondary index cannot be used this way at all: its next_key comes back as the secondary key (389 for a query bounded to action 389), so a truncated secondary read cannot be resumed.

The serial fallback is gone. A resolve failure raises ResolveError; ledgered un-claims the action's global_seq and pages Sentry. Note this is real data loss until someone reindexes the range — demux's cursor advances regardless — but a missing claim can be reindexed and a wrong primary key cannot be undone.

The more-based guard is restored for the objective/action create-path resolvers, whose sets fit in one walk budget (objective 93 → 2 rows, more: false).

Verification

scripts/verify-claim-resolver.js against the prod chain: 636/636 probes returned the contract-truthful id, including probes whose match sits hundreds of ids above the watermark and so must cross several truncated pages. An exhausted pair throws instead of inventing an id.

Remediation

The checked-in mapping is replaced by a generator (scripts/build-claims-id-remediation.py), because a static map goes stale within hours while drift is still growing.

The mapping is derived from claim content (action_id, claimer, proof_photo, proof_code), not sequence position: on prod, 223 of 282 rows in the affected range are already correct and the bad ones are isolated displacements, not a uniform shift, so a position-based alignment yields a wrong and non-monotonic map. The previous static SQL mapped 19907 → 19915 where the proof photos give 19907 → 19922 (19915 is already correct), and one of its targets is now held by a live row, so it would abort on the primary key.

It also repoints notification_history.payload, which embeds the claim id a second time as double-encoded json ({"record":{"id":N}}) with no FK — renumbering only the column left every notification for a moved claim pointing at whichever claim took its old id.

Rehearsed end to end against a local copy of the real prod rows (282 claims, 550 checks, 452 notifications): commits with parked_left 0, orphan_checks 0, payload_mismatches 0, and afterwards all 284 claims match the chain exactly on (id, action_id, claimer, proof_photo), every claim keeping its checks and notifications.

Current output: 59 renumbers + 2 backfills (chain claims 19871 welovecircus and 19904 bananadacult, which never got a DB row — two claimactions for the same pair in one transaction, collapsed by the (created_tx, action_id, claimer_id) dedup guard).