fix: PLTF-2895 dedicated read session for RemoteSandboxService.get_sandbox (avoids idle-in-txn without breaking delete atomicity)

[aivong-openhands]

Summary

RemoteSandboxService.get_sandbox() reads the stored sandbox on the shared, request-scoped AsyncSession and then makes a (slow) runtime API call. That leaves the session "idle in transaction" for the duration of the network call — pinning a pooled connection and blocking autovacuum on v1_remote_sandbox.

This PR reads the stored sandbox on a short-lived, isolated session (_isolated_read_session) so the runtime API call never spans the shared transaction. The shared request session is left completely untouched.

Background — why not just commit the shared session?

This is the same "idle in transaction" problem addressed by OpenHands/OpenHands#14769 (fix: PLTF-2895 release DB transactions before runtime API I/O), which was opened before the app-server code moved to this repo. That PR's approach was to commit() the shared session before the runtime call.

Review of #14769 found that committing the shared session is unsafe (finding #1): the session is shared by every service in a request, so committing it also flushes sibling services' still-pending writes. Concretely, delete_app_conversation interleaves, per conversation:

_delete_from_agent_server(...)  ->  sandbox_service.get_sandbox(...)
_delete_from_database(...)      ->  raw DELETEs, no internal commit

so committing inside get_sandbox would commit the previous iteration's still-pending DELETEs — making the multi-step delete no longer all-or-nothing.

The dedicated-read-session approach here achieves #14769's goal (no transaction spans runtime I/O) without that atomicity regression, because the shared session is never read on or committed.

Test

Adds TestSharedSessionAtomicityDuringDelete — a real SQLAlchemy (SQLite) regression test (no DB mocking) that:

1. seeds an uncommitted sibling DELETE on the shared session,
2. calls get_sandbox,
3. asserts from a separate connection that the sibling write was not committed.

This test fails if get_sandbox ever commits the shared session again. Full test_remote_sandbox_service.py suite: 114 passed; ruff check + ruff format --check clean.

Scope / follow-ups

• This PR converts only get_sandbox (the path exercised by the conversation-delete loop). The other read paths (search_sandboxes, get_sandbox_by_session_api_key, batch_get_sandboxes, pause_old_sandboxes) should get the same treatment — tracked in RemoteSandboxService: extend dedicated read-session fix to remaining read paths (follow-up to #14769, finding #1) OpenHands#16374.
• delete_sandbox's write/revoke-around-network-I/O ordering is a separate design decision (review finding build(deps): bump python from 3.13.7-slim-trixie to 3.14.6-slim-trixie in /containers/app #2), not addressed here.
• _isolated_read_session recovers the async engine from the shared session's sync bind; a cleaner version would inject an async_sessionmaker from DbSessionInjector.

References

• Prior art / superseded approach: fix: PLTF-2895 release DB transactions before runtime API I/O in RemoteSandboxService OpenHands#14769 and its review feedback
• Follow-up for remaining read paths: RemoteSandboxService: extend dedicated read-session fix to remaining read paths (follow-up to #14769, finding #1) OpenHands#16374

---

This PR was created by an AI agent (OpenHands) on behalf of @aivong-openhands.

[linear]

PLTF-2895 INC-95 Prod is down with timeouts follow up

Review in Linear