session-server: keep restart auto-create, but make delete stick

[DavidBellamy]

Why this PR exists

prod already does half of radixark#888: it auto-creates a session on first access. That half gives router-restart tolerance, but on its own it has a bug: a deleted session comes back to life. A GET or chat for a deleted id silently makes a fresh one, so DELETE no longer sticks. The auto-create half also left a session test asserting the old "unknown -> 404" contract, which now contradicts the route.

This PR adds the other half: tombstone explicitly-deleted ids so delete stays deleted, while still auto-creating ids the server has never seen.

Already on prod (the radixark#888 subset — not re-added here)

Pinned to LLM360/miles@prod at e69b51a:

• Auto-create, with no deleted-id guard: get_or_create_session
• TTL eviction: _SESSION_TTL_SECS + _evict_stale_sessions and the _session_last_access map
• GET /sessions/{id} returns empty-200 for any missing id
• chat route calls get_or_create_session

Not on prod (what this PR adds)

• No tombstone: remove_session just drops the session. _deleted_session_ids, _tombstone, and is_deleted do not exist on prod (grep finds none).
• The session test still expects unknown -> 404, which now contradicts the empty-200 route above — a latent failing test on prod.

What this PR changes

• remove_session records the id in a bounded set (the most recent 10k deletes).
• get_or_create_session and the GET /sessions/{id} route return 404 for a tombstoned (deleted) id, instead of recreating it or returning empty.
• An id the server has never seen still auto-creates / returns empty, so restart tolerance is preserved.

Tests (reconciled)

• test_get_session_not_found -> test_get_unknown_session_returns_empty: asserts the intended empty-200 for a never-seen id, fixing the prod contradiction.
• Adds test_get_deleted_session_returns_404 for the tombstone behavior.
• The 4 race tests (test_delete_can_proceed_while_chat_is_mid_proxy, test_chat_during_delete_returns_404, test_chat_after_delete_returns_404, test_rapid_create_chat_delete_cycles) pass unchanged.
• Verified in the miles container: full session suite (test_sessions.py, test_session_pretokenized_e2e.py, test_session_race_conditions.py) is green (56 passed), with the race file green on a repeat run.

[flukeskywalker]

Looks good! A couple of questions:

1. What are the situations in our setup when a chat or GET request for a deleted id might arrive? What happens currently in those situations after the session gets resurrected?
2. Depending on 1, under for which rollout batch sizes would 10k be too low as the number of recently deleted IDs to track?

[flukeskywalker]

@nightlessbaron I think we should merge this, but want to make sure you saw this on the off-chance that this has implications for the request abort issues you were noticing.

[DavidBellamy]

Looks good! A couple of questions:

1. What are the situations in our setup when a chat or GET request for a deleted id might arrive? What happens currently in those situations after the session gets resurrected?
2. Depending on 1, under for which rollout batch sizes would 10k be too low as the number of recently deleted IDs to track?

1. It's never on purpose. Each conversation gets a fresh, unique ID, so a request for a deleted one is always a leftover retry. The most common cause: the agent retries a message after the conversation was already wrapped up and deleted. Before this fix, that retry quietly created a ghost empty conversation that just sat around wasting space for 2 hours. This fix makes it cleanly fail instead.
2. The list only needs to remember an ID long enough for stray retries to stop coming (a couple minutes). 10k is plenty unless you're running so many conversations at once that you delete more than 10,000 within that short window, roughly when batch size times samples-per-prompt gets above ~10k. Will we hit this?