fix(memory): roll back a failed SQLiteSession insert

[LeSingh1]

Summary

_locked_connection() does not manage transactions, and SQLiteSession.add_items had no rollback. When _insert_items raised partway — for example json.dumps() failing on a non-serializable item, which happens after the sessions-table upsert has already opened a write transaction — that transaction was left open on a cached connection (shared for :memory:, thread-local for file DBs).

SQLite then held the write lock for the lifetime of that connection, so every later writer against the same file failed with database is locked, including the same session called from another thread. The wedge outlives the failed call:

control (successful add_items): probe write OK
add_items raised: TypeError Object of type object is not JSON serializable
after failed add_items: probe write FAILED -> database is locked
later add_items FAILED -> OperationalError: database is locked

Roll back explicitly on failure, matching what the AdvancedSQLiteSession subclass already does for its own multi-statement writes.

Test plan

Added test_sqlite_session_failed_add_items_releases_write_lock, which triggers a mid-insert failure and then writes from an independent sqlite3 connection opened with timeout=0 — the busy handler is disabled so a retained lock fails immediately rather than after a 5s wait, keeping the test fast and non-flaky. It fails on main with sqlite3.OperationalError: database is locked and passes with the change. It also asserts the partial sessions-table row was rolled back and that the session remains usable afterwards.

Full file: 41 passed. .agents/skills/code-change-verification/scripts/run.sh passed.

Issue number

N/A — found while auditing session backends for transaction handling on failure paths.

Checks

• I've added new tests, if relevant
• I've run .agents/skills/code-change-verification/scripts/run.sh
• I've confirmed all verification steps pass
• If using Codex, I've run /review before submitting this PR