fix: replace two-step acquire_lock with atomic upsert to prevent TOCTOU race

[patrick-chinchill]

Summary

• Replaced the two-step INSERT/UPDATE lock acquisition in PostgresStateAdapter.acquire_lock() with a single atomic INSERT ... ON CONFLICT DO UPDATE WHERE chat_state_locks.expires_at <= now() upsert
• The previous approach had a TOCTOU race: two concurrent callers could both see the INSERT fail, then both attempt the UPDATE on the expired row
• The new single-statement approach lets Postgres acquire a row lock on the conflicting row, guaranteeing only one caller wins
• Added test_acquire_lock_uses_single_atomic_upsert test that verifies exactly one SQL statement is issued per acquire attempt (new lock, contended lock, and expired lock scenarios)

Closes #19

Test plan

• All 59 existing tests pass (including lock acquire/release/extend/force tests)
• New test verifies single-query execution for all three lock scenarios
• Manual verification against real Postgres with concurrent connections

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request refactors the acquire_lock method in the Postgres state adapter to use a single atomic upsert, replacing the previous two-step process to eliminate a potential TOCTOU race condition. The changes include updating the SQL query to use ON CONFLICT DO UPDATE with an expiration check and adjusting the test suite to verify the single-query behavior. Review feedback suggests simplifying the SQL interval calculation for consistency and replacing a blocking time.sleep() call with await asyncio.sleep() in the asynchronous test.

[gemini-code-assist]

For consistency with the extend_lock implementation (line 269) and to simplify the SQL, you can use the interval multiplication syntax instead of make_interval. This also avoids the explicit cast to float and division.

Suggested change

	VALUES ($1, $2, $3, now() + make_interval(secs => $4::float / 1000))
	VALUES ($1, $2, $3, now() + $4 * interval '1 millisecond')

[gemini-code-assist]

Using time.sleep() in an asynchronous test blocks the event loop. While it might not cause issues in this specific isolated test, it is better practice to use await asyncio.sleep() to allow the event loop to continue running other tasks if necessary.

Suggested change

	time.sleep(0.005)
	await asyncio.sleep(0.005)