Raise on a COMMIT that the server downgrades to ROLLBACK

[Taure]

Problem

pgo:transaction/2,3 reports success even when the transaction was not committed.

When a statement inside the transaction errors and its error is not surfaced as an exception (e.g. a caller ignores the {error, _} return of pgo:query/1,2), PostgreSQL puts the transaction block into the aborted state. A subsequent COMMIT is then downgraded by the server to a ROLLBACK, and PostgreSQL returns the ROLLBACK command tag.

Today both command tags are treated identically:

case pgo_handler:extended_query(Conn, "COMMIT", [], ...) of
    #{command := commit}   -> Result;
    #{command := rollback} -> Result   %% aborted txn: rolled back, but returns Result anyway
end

So the caller receives the function's return value as if everything committed, when in fact the whole transaction was rolled back. That is a silent data-integrity footgun: metrics/audit/side-effects downstream record work that never persisted.

Fix

Raise transaction_rolled_back when the COMMIT comes back as a ROLLBACK. This is consistent with the existing behaviour of pgo:transaction, which already raises (re-raises) when the fun itself throws, so both "the transaction did not commit" paths now behave the same. The rollback outcome is raised after the after block (checkin/erase), so the connection is still returned to the pool cleanly and no spurious extra ROLLBACK is issued.

Tests

Added to pgo_basic_SUITE (clear group):

• transaction_returns_value - the happy path still returns the fun's value and commits inner queries.
• transaction_aborted_raises - an ignored in-transaction error causes pgo:transaction to raise transaction_rolled_back, and the pool/connection remains usable afterward.

Validation note

I could not run the full CT suite locally: a transitive test dependency (chatterbox, via opentelemetry) fails to compile on OTP 28/29 (deprecated prefix-catch), unrelated to this change. The library itself compiles cleanly, and I verified the behaviour end-to-end against a live PostgreSQL - a normal transaction returns its value, an aborted transaction now raises transaction_rolled_back, and the pool is healthy afterward.

Note on the API choice

I went with raising because it matches the existing fun-exception path and surfaces the failure loudly. An alternative that stays within the current any() | {error, any()} return type would be to return {error, transaction_rolled_back} instead. Happy to switch to the non-raising variant if you would prefer to preserve the current non-raising contract for aborted commits.