fix(engine): don't send the first message before the real default loads

[Its-My-Work]

Summary

_globalDefaultEngine starts hardcoded 'api' and only becomes the actual configured default once checkVersion()'s /api/version fetch resolves and calls resolveEngineForView(). A message sent before that fetch lands — in practice, the very first message on a freshly loaded page — went out with curEngine still on that placeholder 'api'.

The server bakes whatever engine arrives into the session's run_engine permanently (server.js ~line 11914), so this silently and irreversibly routed that chat's billing through the API key instead of the user's actually-configured Subscription default, for the life of the chat.

Fix

Capture checkVersion()'s promise as _versionCheckDone and await it at the top of send() — a no-op once already resolved, so this costs nothing beyond the first message of a session.

Verified

• Confirmed against a real deployment: brand-new sessions were landing in the DB with run_engine='api' explicitly set even though the configured default was 'subscription' — never NULL (which would mean "inherit the default").
• After the fix, the first message correctly waits for the real default before it's sent.

Test plan

• Set the default engine to Subscription, hard-refresh the page, immediately send a message as the very first thing in a new session — confirm it resolves to the Subscription engine, not API.

🤖 Generated with Claude Code

https://claude.ai/code/session_011E2bJQ2sL9LgEWosjvydTR

[Its-My-Work]

Closing this one — a different, more concrete bug (mobile engine-chip highlight sync, #105) turned out to be the actual cause of the reported symptom. Superseding with #105.