Backfill chestshop_sale.txn_id for existing sales (~787K NULL rows per network)

Sibling of PAR-234 (forward fix). Once new sales populate txn_id, backfill the historical rows so the whole sales back‑catalogue links to the ledger — it's genuinely useful data (sale↔money drill‑through, reconciliation, analytics).

Scope

Pair each NULL‑txn_id chestshop_sale row to its ledger transaction and set txn_id. As of now: ~787,092 rows in democracycraft (all NULL); statecraft similar.

Pairing approach

For each sale, match a ChestShop ledger txn (plugin_system='ChestShop') by:

• shop side: shop_account_id (or shop_owner_uuid_bin) appears as a posting account;
• counterparty: customer_uuid_bin;
• amount: total_price == ABS(ledger_postings.amount);
• time: occurred_at ≈ settlement_time within a tight window (±a few seconds).

Under the legacy two‑hop, a sale maps to a txn pair (buyer→System, System→seller) — pick and document a canonical leg (e.g. the seller‑credit txn) to store. This is the same pairing PAR‑159 needs for the explorer two‑hop collapse, so share the logic.

Caveats

• Fuzzy: ambiguous when the same shop sells the same item at the same price within the window — recover unambiguous matches, log/skip the rest, and report a match‑rate. Don't guess a 1:1 where it isn't certain.
• Idempotent: only fills WHERE txn_id IS NULL; safe to re‑run.
• Bounded/batched: pairing ~787K sales against ~1.57M ChestShop txns — chunk by time window; run off‑peak.

Ops

One‑off data migration per environment (democracycraft, statecraft), run against prod via a controlled/manual path (like the Flyway/admin one‑offs), not auto‑applied.

Acceptance

• A high share of pre‑fix sales get a correct txn_id (target/report the %); unmatched rows logged with a reason and left NULL.
• Spot‑check: linked total_price equals the matched posting amount; re‑running changes nothing.

Depends on / pairs with PAR-234; shares pairing logic with PAR-159.