refactor(tracker): run tx-tracker GQL outside the DB transaction

[ipdae]

What

track_tx() opened a session, SELECTed up to 200 unsettled claims (tx_status IN (STAGED, INVALID)), then held that transaction open while it fanned out a per-claim headless GQL batch (process()), committing only at the very end. This splits it into three phases so no transaction is held across the RPC:

1. Read the unsettled claims in a short transaction, capture (id, planet_id, tx_id) as plain scalars, and close() the session before any RPC.
2. GQL batch with no DB transaction held open.
3. Write the resolved statuses in a fresh, short transaction.

Why

Found while investigating the mainnet seasonpass DB after the #308 deploy. Live pg_stat_activity showed this exact query sitting idle-in-transaction for 448s:

SELECT claim.* FROM claim WHERE tx_status IN ('STAGED','INVALID') ORDER BY claim.id LIMIT 200

It's a plain SELECT (AccessShareLock, no FOR UPDATE), so it blocked no other query and caused no alarms — but the long-lived transaction pinned the xmin horizon and blocked autovacuum on the hot tables:

• user_season_pass — last_autovacuum = None (never autovacuumed), ~292k dead tuples
• claim — not vacuumed since the prior manual run, ~175k dead tuples

This is the same anti-pattern the API status paths fixed in #308, just living in the tracker (which #308 didn't touch). The tracker runs track_tx() on a 10s loop, so the xmin pin recurs continuously whenever a node is slow.

Correctness notes

• The write now guards on tx_id as well as id: UPDATE claim SET tx_status=... WHERE id=:id AND tx_id=:tx_id. Decoupling the read from the write widens the read→write gap, so a claim that was re-staged with a new tx in between is now left untouched (picked up next cycle) instead of being clobbered with a stale status. process() returns the same tx_id it was given, so this is exactly the tx we resolved.
• start_id/end_id/count logging and the STAGED/INVALID selection are unchanged.
• The per-claim process() semantics, planet conversion (PlanetID(...)), and thread pool (max_workers=10) are unchanged.
• Also drops a dead import os.

Testing

The tracker has no existing test suite and the models use postgres-only types (ARRAY/ENUM/JSONB), so an in-memory harness is disproportionate here. Verified via py_compile + black/isort/autoflake (pre-commit). A tracker test harness is a reasonable follow-up. Behavior is otherwise a straight restructuring of the existing read→GQL→write flow.

Independent of #306/#308 (touches apps/tracker only) — targets main directly.

🤖 Generated with Claude Code