fix(chat): resolve the request's model inside the stream's error boundary

Adversarial review of this stack, pre-push: the router allowlist check
added earlier in the branch sat one line above the try block it belonged
in.

WHY THIS MATTERS
runLLMStream's `try` is not decoration - it is the whole error contract
of an SSE turn. Inside it, a failure flushes the partial assistant text,
pushes an `{ type: "error" }` event that the route persists with the
turn, and throws AssistantStreamError carrying both. Outside it, a
failure is a bare rejection: no error event, no flushed text, and the
client is left with a stream that simply stops.

`resolveRequestedModel` reads user_router_models. That is a database
call, so it can fail for every ordinary reason a database call fails -
a statement timeout, a connection reset, a paused project. Placed above
the try, one such blip took the un-instrumented path.

HOW IT WORKS NOW
The call moves inside the try, immediately after the abort check.
Behavior on the happy path is identical (the resolved model is still
what reaches streamChatWithTools); the only change is which machinery
handles a failure - now the same one that handles a mid-stream adapter
error.

Tests: streamingModelAllowlist.test.ts gains a case whose
user_router_models read returns a 57014 statement-timeout error and
asserts the rejection is an AssistantStreamError carrying an error
event. Pre-fix it fails with "expected { code: '57014', ... } to be an
instance of AssistantStreamError" - the raw PostgREST error object
escaping, which is exactly the bug.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>