fix(claims): make verifyClaim block-atomic, idempotent, non-swallowing

[lucca65]

Problem

Claims can end up stuck pending in Postgres while approved on chain, making them "unapprovable": the UI reads the DB status, offers a vote, and the chain rejects it with Can't vote on already verified claim. Confirmed on muda claim 19879 — chain had 2/2 approving checks (majority reached), Postgres had only 1; validator ivamdasilvac's verifyclaim was never indexed.

Root cause

The old verifyClaim ran its writes inside a nested db.withTransaction on a separate connection and swallowed every error with .catch(logError). On a transient failure the check write rolled back while demux's outer block tx still committed _index_state past the block — the vote was lost and never retried.

Fix

• Block-atomic: write on the block-level db so the check insert, status recompute, and the _processed_actions ledger row commit or roll back together. A transient error now rolls back the whole block → demux retries it.
• Idempotent: INSERT ... ON CONFLICT (claim_id, validator_id) DO NOTHING (no count-then-insert race; check_added trigger doesn't re-fire on replay).
• No crash-loop: resolve claim/action/verifier before the insert; skip-and-log if any is missing (id drift / DB behind chain) instead of throwing — a throw here would deterministically crash-loop the indexer under pm2. Matches assignRole/upsertAction.
• usages_left: guarded with > 0 (no negatives).
• Tripwire: GetActionsReader._loadNextBatch now logs loudly if get_actions returns a first account_action_seq ahead of the requested cursor (a history hole).

Deploy notes

• Hard-depends on checks_claim_validator_uniq + _processed_actions (both present in prod).
• After restart, watch pm2 jlist restart_time per the runbook (crash-loop guard).
• Recovers stuck claims via reindex of the affected block range (now idempotent), e.g. claim 19879.

Staff-reviewed; verdict SHIP.

🤖 Generated with Claude Code