assistant: an expired session silently starts a new conversation and files it as a second analysis

Leave a saved conversation open past the assistant session TTL (2 hours), type
another message, and the server quietly starts a brand new conversation while
your screen still shows the whole thread.

`assistant_agent.py:1080-1094` resolves the session id like this:

```python
state = None
if session_id:
try:
state = await self.session_service.require_session(
session_id, owner_keycloak_sub
)
except KeyError:
state = None
if state is None:
state = await self.session_service.create_session(
owner_keycloak_sub=owner_keycloak_sub
)
```

An expired id raises `KeyError` and falls straight through to `create_session`,
which produces an empty state -- no messages, no `saved_analysis_id`. The agent
answers with no memory of the conversation, and auto-save then files that single
turn as a new row, so the account page grows a stub analysis next to the real one
it came from.

The client can't tell: `useAssistantChat` keeps rendering its own messages array
and adopts whatever `session_id` comes back.

Two halves worth fixing:

- **Recover instead of starting over.** The dead session id is still the saved
analysis's `source_session`, so the row is findable -- rehydrate from it the way
`POST /saved_analyses/{id}/open` does, and repoint. #1689 added the durable
`saved_analysis_id` on `SessionState` that makes this cheap.
- **Failing that, say so.** If the response's `session_id` differs from the one
sent, the conversation on screen is no longer the one the server is answering
from, and the UI should stop pretending otherwise.

Pre-existing, not a regression from #1689 -- but that PR is what makes the first
option small. Found by copilot reviewing #1689.

Read assistant_agent.py:1080-1094 and trace the POST /saved_analyses/{id}/open flow, then inspect useAssistantChat's handling of messages and session_id. Reproduce the expired-session case after the two-hour TTL. Done means the saved conversation is recovered and repointed, or the UI clearly stops presenting the old thread when the response uses a different session_id.

Written by the indexing model from the issue text.