Auto-save: missing users row maps to a misleading 409 and a silent no-op per turn

Part of #1707. Found in the review of #1689.

## Problem

`backend/api/app/api/v1/assistant.py` (`save_session_to_account`, around line 269) maps every `None` from `persist()` to `409 "Nothing to save yet"`. But `_write` in `analysis_store.py` (lines 115–116) also returns `None` when `get_user_by_keycloak_sub` finds no `users` row. That's a different condition and it gets the wrong status, and on the per-turn `record()` path it's a silent no-op with no log or Sentry event.

## Failure scenario

A user with a valid `brc_session` whose `users` row is gone (DB restore, manual cleanup; `get_current_user_db` already treats this as reachable with its 503 "Authenticated user is not provisioned"):

- every chat turn runs `record()` → `_write` → `if user is None: return None` → `saved=False`, no diagnostic;
- the frontend then POSTs `/assistant/session/{id}/save` → 409 → swallowed client-side.

## Suggested fix

Use `get_current_user_db` (or otherwise distinguish the missing-user case) in `save_session_to_account`, and log / send to Sentry from the `user is None` branch in `_write`.

Start with backend/api/app/api/v1/assistant.py at save_session_to_account, then inspect _write in analysis_store.py and the get_current_user_db behavior described in the issue. Trace the missing-users-row path through record() and the save endpoint. Done means the missing-user condition is distinguishable from an empty session and produces the intended diagnostic signal rather than a silent no-op.

Written by the indexing model from the issue text.