fix: Stale previous_response_id is accepted after runtime eviction, branching the wrong conversation

[sam-saffron-jarvis]

What

• track the latest response ID per session outside the runtime so chaining validation survives runtime recreation
• use that server-wide latest response ID as a fallback when a recreated runtime has no in-memory lastResponseID yet
• clear the cached latest response ID when starting a fresh conversation and add a regression test covering stale previous_response_id after runtime recreation

Why

The stale-chain guard only worked when the live runtime still had lastResponseID in memory. After a runtime was evicted and recreated, older previous_response_id values could still resolve through responseToSession but would skip the stale check, causing the request to run against the wrong conversation state. Persisting the latest response ID at the server level preserves the latest-only chaining check across runtime recreation and prevents silent conversation branching.

[SamSaffron]

Closing in favor of consolidated local changeset on branch pr-consolidation. The change from this PR was folded in along with: #387, #389, #390, #391, #400, #401, #402, #403, #404. Build and full test suite pass.