Auto-anchor pending receipts via scheduled OTS re-verification

[MrNova50]

closes #1

PR Description:

Problem
A minted receipt stays pending until a Bitcoin block confirms and someone manually clicks "Re-verify receipt" on the dashboard. Anchoring depends on a human remembering to come back — the exact silent friction this project exists to eliminate.

Changes

• Added a Convex cron (every ~10 min) running a new internal action internal.attestations.reverifyPending.
• Extracted the verify-mode logic from runOts (src/convex/ots.ts) into a shared verifyReceipt() helper, now used by both the manual "Re-verify receipt" button and the cron — single source of truth, no duplicated logic.
• The action queries pending attestations with stored receipt bytes (batched per run), verifies each, and calls the existing internal.attestations.setAnchored on success with block height/time — unchanged from the manual path.
• Added verifyAttemptCount and lastVerifiedAt fields, with simple backoff so repeatedly-failing receipts aren't retried every cycle — keeps us polite to OTS calendars and mempool.space.
• Added a verificationAttempts table logging each attempt's timestamp and outcome (success/error), for auditability.
• Guarded against reprocessing already-anchored receipts for idempotency.
• Surfaced lastVerifiedAt on the receipt card (reactive query, no polling needed) so the mechanism is legible to users.

Testing

• Unit tested verifyReceipt() against mocked pending/confirmed/error calendar responses.
• Minted a receipt, waited for real block confirmation, confirmed it flipped to anchored with zero dashboard interaction.
• Re-ran the cron against already-anchored and already-failed receipts to confirm idempotency and backoff behavior.