fix(postgres): give every transaction its own db_version and restart seq

[andinux]

Fixes #69.

Cause

The step 1 blocker in the issue (the cached db_version reloading with a lower value) came from the PostgreSQL SQL_DBVERSION_BUILD_QUERY. It built a UNION ALL of one MAX(db_version) per meta table but had no outer MAX, unlike SQLite, and only the first row was read. With more than one synced table, consecutive transactions writing another table all took the same db_version: three separate inserts into a second table landed on db_version 1.

Changes

• Reload query (sql_postgresql.c): wrap the union in COALESCE(MAX(version), 0) and include pre_alter_dbversion, as SQLite does.
• Transaction callback (cloudsync_postgresql.c): RegisterXactCallback closes each transaction the way the SQLite commit/rollback hooks do, via the new cloudsync_transaction_end. seq restarts at 0, and the next transaction takes a new db_version even while another session pins xmin (defects 1 and 2). It acts only when the transaction took a db_version, so read-only transactions keep the cache.
• Apply (cloudsync_payload_apply): inside a caller's transaction, which is always the case on PostgreSQL, the local db_version is closed at every source db_version boundary, so remote versions no longer collapse into duplicate (db_version, seq) pairs (defect 3). The version is also closed after the last group and around each fragment value, so local writes in the same transaction take their own. Closing only marks the pending version (the next change takes pending + 1) and never promotes it into the committed cache, so a rolled back apply leaves cloudsync_db_version() unchanged. It is a no-op after the per-db_version savepoint release on SQLite autocommit.

C-only: no cloudsync.sql.in change and no migration.

Tests

• New: test_db_version_per_transaction (SQLite) and test/postgresql/66_db_version_per_transaction.sql. Both run the same scenario with the same expected numbering, plus the pinned-xmin case on PostgreSQL.
• New: test_db_version_apply_in_transaction (SQLite) and matching cases in test 66: local writes around an apply in one transaction, and a rolled back apply.
• SQLite unit tests: pass.
• PostgreSQL 17 debug: 562 PASS, 0 failures (tests 28 and 59 included).
• Supabase (17.6.1.143): 560 PASS, 0 failures.
• Combined with feat: bound what one cloudsync_payload_chunks() call prepares #77 (feat/payload-chunks-window-cap): PostgreSQL 565 PASS; SQLite passes. The only conflict is one line in test/postgresql/full_test.sql (both add a test; keep both).

Not covered: two backends picking the same next db_version concurrently, which predates this change.

🤖 Generated with Claude Code