Two distinct timeout causes, both surfacing as the client's 30s 'Request timed
out' toast with no server-side signal:
A) /api/session/move acquired the per-session agent lock with a bare unbounded
'with _get_session_agent_lock(sid):'. The streaming thread holds that same
lock during checkpoint saves; on slow file I/O (WSL/DrvFs) the move could
block past the client abort. Now acquires with timeout=5 and returns HTTP 503
on contention (lock kept, not dropped, since s.save() still races the writer).
B) /api/projects/delete unlinked every assigned session via get_session()+save()
— O(N) full-messages reserialize. For an actively-streaming session we now
clear project_id on the LIVE CACHED Session object under LOCK (the streaming
thread persists it on its next save — the worker always does a final save at
turn completion) instead of issuing a competing s.save(); falls back to a
direct save when not cached. Non-streaming sessions unchanged.
Also guards the '+ New project and move' shortcut (sessions.js) against the new
503 so it shows a toast instead of an unhandled rejection, keeping the #2551
authoritative refetch in both the success and catch paths.
Adds tests/test_issue3746_session_move_delete_timeout.py (behavioral lock-timeout
test + structural guards for both handlers + the frontend 503 guard). Widened the
#2551 new-project-refetch test's fixed byte-window to a block-scoped search so the
try/catch wrap (which preserves the refetch) doesn't trip a brittle offset assertion.
Co-authored-by: nesquena-hermes <nesquena-hermes@users.noreply.github.com>
