assistant: deleting a saved analysis doesn't stop its live session from re-creating it

Delete an analysis from `/account` while its conversation is still open in
another tab, send one more message there, and it comes back.

`remove_saved_analysis` deletes the row and nothing else. The Redis session is
still alive and the browser still holds its cookie and localStorage pointer, so
the next turn's auto-save looks for a row, finds none (we just deleted it), and
inserts a fresh one carrying the whole conversation. New id, same content.

It's self-limiting -- the turn after that finds the row it just made and updates
it, so you get one resurrection rather than one per turn. But "I deleted this and
it came back" is the kind of thing people stop trusting a delete button over.

Options:

- Delete the live session alongside the row. Honest, though the open tab then
lands in the expired-session behaviour described in #1691, which is its own
problem.
- Or write a tombstone that auto-save honors, if we'd rather not yank a session
out from under an active tab.

Pre-existing. Found by copilot reviewing #1689.

Start at remove_saved_analysis and the live-session auto-save path described in the issue, then reproduce the account deletion and follow-up message flow with an open conversation. Trace how the Redis session, cookie, and localStorage pointer are used after deletion. Done means deleting a saved analysis prevents that session from recreating it, with behavior for the open tab matching the chosen approach and a regression test covering resurrection.

Written by the indexing model from the issue text.