feat: keep a session's transaction alive across batches

[aesslinger]

Replaces #114 (a fork-based PR whose head branch couldn't be updated from the upstream side). All of @egertaia's original work is preserved here with full attribution; this branch simply merges it onto current main (with #119/#123) and resolves the resulting conflicts.

What

Companion to TabularisDB/tabularis#801, which plumbs the session id through the host. Either can merge first: the wire change is backward compatible in both directions.

execute_query_batch acquires one pooled connection for the whole batch, so BEGIN … COMMIT inside a single script works. The workflow the transaction exists for does not:

Run 1:  BEGIN; UPDATE accounts SET balance = 0 WHERE id = 42;
Run 2:  SELECT balance FROM accounts WHERE id = 42;   -- check before committing
Run 3:  COMMIT;

Each run is its own RPC call (and a one-statement run arrives as execute_query, not execute_query_batch), so the connection goes back to the pool in between. Run 2 can land on a different connection and show pre-transaction data; run 3 reports there is no transaction in progress while the real transaction stays open elsewhere.

It is also a hazard for unrelated queries. The pool is configured with RecyclingMethod::Fast, which resets nothing, so the stranded connection returns to the pool still inside the transaction, holding its locks, and the next borrower runs inside it.

Fix

When the host sends a session_id, a batch that leaves an explicit transaction open keeps its connection pinned to that session, so the next batch from the same session continues the same transaction. Committing, rolling back, an explicit release_session, shutdown, or 30 minutes idle releases it. A pinned connection is always rolled back before it goes back to the pool, so an open transaction can no longer leak into an unrelated query. Pinning is lazy: a session that never opens a transaction holds nothing and behaves exactly as before.

• transaction_effect() in handlers/query.rs (BEGIN, START TRANSACTION, COMMIT, END, ROLLBACK, ABORT, PREPARE TRANSACTION, and ... AND CHAIN), next to the existing strip_leading_sql_comments it builds on.
• session.rs: the registry, the ROLLBACK-before-release rule, and sweep_idle(), run from the existing 10-minute run_pool_cleanup timer.
• run_batch_in_session, extracted from execute_query_batch, reuses the session's pinned connection and re-pins it if a transaction is still open afterwards. execute_query goes through it as a one-statement batch, so a single statement and a batch take the same session path.
• release_session RPC method; shutdown releases every pinned session.

Wire compatibility (backward compatible, no companion required to merge)

• session_id is optional on both execute_query and execute_query_batch. Without it the behaviour and the responses are byte-for-byte what they are today: a bare QueryResult and a bare array of per-statement results. Hosts older than tabularis#801 are unaffected — verified against upstream/main of tabularis, which sends no session_id today.
• With it, the replies are { "result": {...}, "in_transaction": bool } and { "results": [...], "in_transaction": bool }. The host side accepts both shapes permanently, and recognises the wrapper by in_transaction being present.
• release_session is a new method; a host that never calls it loses nothing (the idle sweep and shutdown still reclaim connections).

Status note

The transaction-pinning feature is dormant until tabularis#801 ships in a host release — no current host sends session_id, so the new session path is unreachable in production until then. This PR is safe to merge independently (zero breakage, verified) and lights up when #801 lands. See the discussion on the closed #114 for the compatibility analysis.

Merge onto current main

Merged origin/main (with #119/#123) and resolved:

• CHANGELOG.md — took the bracketed ## [Unreleased] convention; merged all Added/Fixed entries (the get_table_ddl/get_schema_snapshot/batch entries from feat: implement get_table_ddl RPC method for dump support #119/feat: implement get_schema_snapshot and batch metadata RPCs (#121) #123 plus this PR's session_id/release_session Added and the rollback-before-release Fixed).
• tests/live_db.rs — kept all live tests (this PR's deferred-constraint session test + feat: implement get_table_ddl RPC method for dump support #119's get_table_ddl tests + feat: implement get_schema_snapshot and batch metadata RPCs (#121) #123's get_schema_snapshot test).

src/rpc.rs, handlers/query.rs, session.rs, and README.md auto-merged cleanly (the dispatch additions occupy disjoint regions). All @egertaia commits preserved with original attribution.

Verification

• cargo build --release
• Cross-repo 83-test byte-for-byte parity suite (POSTGRES_PLUGIN_BIN against tabularis' src-tauri/tests/postgres_integration parity*): 83/83 pass — no existing behavior regressed.
• 356 unit tests pass (including the 9 transaction_effect/in_transaction_after cases).
• 30 live-DB tests pass against a real postgres:16 instance — including commit_that_fails_on_a_deferred_constraint_releases_the_session, which had not previously been run live and now passes.
• cargo clippy --all-targets -- -D warnings; cargo fmt --all --check; npx markdownlint CHANGELOG.md — all clean.

Supersedes and closes #114.

---

Generated with Lilly Code

[github-actions]

Version suggestion

Based on this PR's title (feat) and the prerelease:rc label:

Current	1.0.0-rc.4
Suggested next tag	v1.0.0-rc.5

This is informational only — no tag or release is created automatically yet.