Release savepoints after rollback

[ShiroKSH]

Summary

• release a savepoint after rolling it back
• keep rollback and release as separate SQLite statements
• cover nested cleanup and successful transaction reuse after a rollback

Root cause

ROLLBACK TO SAVEPOINT rewinds database changes but leaves the savepoint active. The connection therefore remained inside a transaction after a throwing outermost savepoint block, causing the next transaction to fail with cannot start a transaction within a transaction.

Impact

Failed savepoint blocks now leave the connection ready for subsequent transactions. Normal transaction and successful savepoint behavior are unchanged.

Validation

• git diff --check
• targeted SQLite state-transition reproduction for nested rollback/release cleanup and subsequent transaction reuse

[ShiroKSH]

@stephencelis We'd appreciate it if you could take a look at this pull request when you have a chance.

[jberkel]

Thanks for your contribution, will look at it soon

[ShiroKSH]

Hi maintainers, this PR has been open for over two weeks. When you have a moment, I would appreciate a review. Thank you.

[jberkel]

Can you get the build green first? there are some lint errors.

[ShiroKSH]

Fixed in ed1bd70. I moved the internal transaction helper into a Connection extension so the class stays within SwiftLint's type-body limit; behavior is unchanged. CI is running again.

[ShiroKSH]

The CI setup fix is pushed in ac903cc. GitHub is waiting for maintainer approval before it can run workflows for the updated fork branch. Could you approve and run the workflow when convenient?

[jberkel]

Thanks for the tuist fix

[jberkel]

Not sure why the SPM integration tests now fail. Perhaps an update of the macos-15 image (unfortunately these can't be pinned). I'm travelling at the moment and don't have always access to wifi, but will look at this later.

[ShiroKSH]

CI follow-up pushed in 99b5938.

The earlier macOS 15 SPM SIGKILL was runner-specific: the current #1372 run passes the SPM integration step on both macOS 15 and macOS 26. The remaining Tuist failure comes from SwifterPM expecting Tuist/Package.resolved while Swift 6.2 no longer creates it for this package graph. The new commit uses Tuist's supported TUIST_USE_SWIFTERPM=0 fallback, avoiding toolchain-dependent lockfile generation.

The new workflow is waiting for maintainer approval. Could you approve and run it when convenient?