[Bug]: ResponseStore leaves stale conversation mappings after eviction/deletion

[CoinTheHat]

Bug description

ResponseStore.put() evicts old rows from the responses table, and ResponseStore.delete() removes a response row, but neither path clears conversations rows that still point to those deleted response IDs. This leaves stale conversation mappings behind.

Concrete repro

1. POST /v1/responses with conversation="chat-a" → stores resp_1
2. Evict or delete resp_1
3. get_conversation("chat-a") still returns resp_1
4. The next /v1/responses call with conversation="chat-a" fails with 404 Previous response not found

Expected behavior

After a response is evicted or deleted, any conversation mappings referencing that response should also be cleaned up. Reusing the conversation name should start a fresh conversation, not 404.

Affected file

gateway/platforms/api_server.py — ResponseStore class

Fix

Fixed in #2605:

• ResponseStore.put() now collects evicted response IDs and deletes their conversations rows before removing the responses rows
• ResponseStore.delete() now also deletes conversations rows where response_id matches
• Added 3 regression tests covering delete, eviction, and handler-level reuse

[ygd58]

Submitted a fix in PR #2606.

Note: The root cause is that _conversations lives on APIServerAdapter, not inside ResponseStore. PR #2605 adds cleanup inside ResponseStore but ResponseStore has no access to _conversations — the fix must happen at the APIServerAdapter level.

This PR fixes both paths at the correct layer:

• Delete path: after _response_store.delete(), removes _conversations entries pointing to the deleted response_id
• Eviction path: ResponseStore.put() now returns evicted IDs, and the caller cleans up _conversations for each evicted ID