fix: avoid price_history crash when price sync races a full sync

[hiddenbanana]

Summary

perform_price_sync can overlap with a full sync. Both jobs update the same
tracked cards and record one price_history row per card and day, while their
long-running sessions commit only after all network work has finished.

The previous SELECT-then-INSERT flow could therefore observe no row, keep a
pending PriceHistory object for the rest of the sync, and then fail the final
commit if another sync inserted the same (card_id, date) first. That discarded
the complete transaction, including unrelated card updates.

This was observed in production:

psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "uq_price_history_card_date"
DETAIL: Key (card_id, date)=(SV4a-121_ja, 2026-07-26) already exists.

Final implementation

• Buffer price-history candidates while the sync performs its network work.
• Serialize only the short final PostgreSQL write phase with a
  transaction-scoped advisory lock.
• Flush pending card rows before their price-history rows for foreign-key
  safety.
• Deduplicate and sort cards by ID to guarantee a stable lock order.
• Write bounded batches of 100 rows using
  INSERT ... ON CONFLICT (card_id, date) DO NOTHING.
• Use the same sorted, bounded upsert behavior on SQLite.
• Roll back an aborted price-sync transaction before recording its error state.
• Update the application version to 1.27.1.
• Integrate and validate against current main.

This avoids thousands of per-card database round trips and prevents locks from
being held throughout the long network phase. A completed competing sync simply
makes the later history rows safe no-ops.

Testing

• 281 backend tests passed.
• Genuine PostgreSQL 18 concurrency test passed with one transaction held
  uncommitted while a second writes the same cards in reverse caller order.
• The PostgreSQL concurrency test was repeated several times without duplicate
  errors or deadlocks.
• A 205-card regression test confirms three bounded bulk statements are used
  instead of 205 individual writes.
• Transaction rollback/error-state coverage passed.
• 79 frontend tests passed.
• Backend and frontend Docker builds passed.
• Production frontend build and version consistency check passed.
• A PostgreSQL-backed Docker stack started successfully and passed its health
  check.

[Git-Romer]

@hiddenbanana, good catch with this race condition. The production logs made it clear how two overlapping syncs could cause an entire sync to fail at the final commit.

I used your ON CONFLICT fix as the foundation and added a few changes:

• Price history writes are now collected and saved at the end of the sync.
• Rows are written in sorted bulk batches instead of one at a time.
• PostgreSQL only locks the short final write phase.
• Failed transactions now recover cleanly.
• The tests now run two syncs concurrently and cover duplicate prevention, deadlocks, and batching.

Everything passes against current main, including 281 backend tests, 79 frontend tests, and repeated PostgreSQL concurrency tests. I also updated the version to 1.27.1.

The PR is ready now. Your report and initial fix helped turn a difficult intermittent failure into a more reliable and efficient sync process. Thank you!