fix(db): lock sessions individually so SQL tabs execute concurrently

[feigeCode]

Description

Problem. Two SQL tabs could not execute concurrently. While tab A was running a statement, tab B was blocked — even when it was connected to a different database — and metadata / table-data / config reads queued behind it as well.

Root cause. ConnectionManager stored every session in one global map behind a single RwLock. get_session_connection() took the write lock on that map and handed it to SessionConnectionGuard, which held it for the whole lifetime of a statement (conn.execute(..).await, conn.execute_streaming(..).await, …) — about 25 call sites followed this pattern. Since tokio::sync::RwLock is fair, the queued writer also blocked subsequent readers, so unrelated sessions serialized on the same lock. Lock granularity was the only issue: the driver layer has no global lock, and try_acquire_session already gives each session its own physical connection.

Fix — lock per session instead of per manager.

• ConnectionSession.connection becomes Arc<AsyncMutex<Box<dyn DbConnection + Send + Sync>>>, so a statement only locks the connection it uses.
• New SessionState behind its own StdMutex; bookkeeping reads no longer wait for an in-flight statement. All ConnectionSession methods now take &self.
• The session map holds Arc<ConnectionSession>; get_session_connection() holds the map lock only to look the session up and claim it, then releases it. SessionConnectionGuard now owns that session's connection lock and no longer needs a lifetime parameter, so the existing call sites are unchanged.
• Teardown paths (close_session, remove_all_sessions, cleanup_expired_sessions, release_session_internal) now detach the session under the map lock and close it outside it, so disconnecting one connection no longer stalls every other tab.
• Preserved semantics: the same session stays exclusive (a physical connection is still serialized), busy/transactional sessions are never reclaimed, and cancel/close still wait for the running statement to finish.

Review follow-up (commit 24e87f8)

The first revision fixed the guard granularity but left the session-pool paths inconsistent. Three issues were raised in review; all three are fixed in 24e87f862, together with the lock-order invariant they depend on.

1. [P1] Reuse still waited on a connection lock while holding the session table lock. try_acquire_session called session.config().await for every candidate while holding sessions.write(), so one session busy with a long statement stalled the whole pool — the original bug, still reachable through create_session() (the follow-up path used by metadata, table data and plugin operations). The session table lock is now held only to pick and claim a candidate: the live identity check and the ping happen after it is released, a candidate that fails validation is skipped instead of stalling, and candidates are matched against a cached DatabaseIdentity (refreshed by verify_and_sync_database, the only writer of DbConnectionConfig::database, so it cannot drift).

2. [P2] A stale release could clear a newer claim. release_session_internal finishing after the next get_session_connection had already claimed the session marked a busy session as idle, and the idle sweep could then recycle the connection of a running statement (session not found). Claims are now reference counted, with a one-shot reservation: create_session / try_acquire_session reserve the session, the statement's get_session_connection consumes that reservation, so each statement adds exactly one claim and its release returns the counter to zero. Two concurrent create_session calls still never share a session, and an unconsumed reservation cannot pin a session forever (it is still collectable after the idle timeout).

3. [P2] disconnect() could run twice. release_session_internal called close() even when detach_session() returned None, racing a concurrent close_session / remove_all_sessions. Only the task that actually removes the session from the pool closes it now, and try_acquire_session discards a stale session through that same path.

Also included: get_session_connection re-checks that the session is still pooled after it took the connection, so a connection removed meanwhile is never handed out; list_sessions reads the cached identity instead of the live config; get_session_config still returns the live config but no longer waits while holding the session table lock. Lock order is now only "connection lock, then session table lock", and no path holds the session table lock while awaiting a connection lock.

Break Changes

None. Public signatures are unchanged; get_session_connection now returns SessionConnectionGuard without a lifetime parameter, which only relaxes the previous borrow.

How to Test

cargo test -p db --lib            # 1308 passed, incl. 43 manager tests
cargo test -p db                  # full suite, incl. real_postgres / real_sqlite
cargo test -p db_view --lib       # 717 passed
cargo check -p main               # OK
cargo clippy -p db --all-targets  # only the 3 pre-existing warnings in manager.rs
cargo run                         # not run (story tests need a real database / UI session)

Regression tests reproduce the reported bug and fail with a timeout before this change:

• session_connection_guards_do_not_serialize_different_sessions — a second session must acquire its connection without waiting for the first session's statement, while the same session must remain exclusive.
• executing_on_one_session_does_not_block_another_session — while session A is blocked inside execute, session B's execute_session must complete within the timeout.

Five more tests cover the three review issues listed above (each reproduced red first, then green):

• try_acquire_session_does_not_block_the_pool_while_a_session_is_busy — while a session is busy with a statement, an unrelated connection must still be able to take its own session, and the busy session must not be handed out again.
• overlapping_release_keeps_the_next_statement_claim and releasing_a_session_does_not_report_the_next_statement_as_idle — a release that finishes after the next statement claimed the session must not report it as idle.
• concurrent_release_and_close_disconnect_the_session_once — release and close_session racing on one session must disconnect the physical connection exactly once.
• a_statement_claims_and_releases_a_session_exactly_once — a claim/release cycle returns the session to idle, reusable, and eligible for idle cleanup.

Manual check: open two SQL tabs on the same connection, start a long-running query in tab A, then execute a query in tab B. B returns immediately instead of queueing until A finishes.

AI Assistance

This refactor was drafted with an AI assistant (Finch) and reviewed line by line afterwards. Every command listed above was executed locally on this branch; the failing-before / passing-after behaviour of the regression tests was verified manually.

Checklist

• I have read the CONTRIBUTING document and followed the guidelines.
• Reviewed the changes in this PR and confirmed AI generated code (If any) is accurate.
• Passed cargo run for story tests related to the changes.
• Tested macOS, Windows and Linux platforms performance (if the change is platform-specific)

Note: the story tests (cargo run) were not run — the verification above is test-suite level. Platform testing was done on macOS only; the change is platform-independent Rust code in the db layer, but Windows/Linux runs are still pending.