fix(gateway): resolve a session row's model under its own profile, not the launcher's

[OmarB97]

What's wrong

_ensure_session_db_row writes the first DB row for a desktop/TUI session. It is called from prompt.submit on the RPC thread — before the per-turn set_hermes_home_override the turn thread binds — so every HERMES_HOME read inside it answers for the launch profile.

The model fallback is where that becomes permanent:

row_model = str(override.get("model") or "").strip() or _resolve_model()

With no composer model, _resolve_model() → _load_cfg(), which honours a bound override but has none here, so it reads the launch profile's config.yaml. A session created under profile: "worker" gets the launcher's default model written into worker's state.db.

And it cannot be repaired. _insert_session_row upserts under model = COALESCE(sessions.model, excluded.model) — first writer wins — so the agent's own correct lazy-create in run_agent.py is a no-op against it.

This is the same failure the comment directly above that line was written to close:

Writing the global default here used to win the INSERT-OR-IGNORE race against the agent's own correct lazy-create

That was fixed for the composer-override case. The no-override + foreign-profile case still hit it.

The fix

Bind the session's own profile_home around the resolution (new _profile_home_bound context manager). The fallback now names the model that profile is actually configured for — the same value _make_agent resolves under the same binding — so both writers agree and COALESCE has nothing to freeze.

An explicit composer pick still wins untouched: the anti-race intent is unchanged, and a session with no profile_home takes the identical path it did before.

All four callers of the helper — prompt.submit, the /model switch marker, /title, and handoff — are on unbound RPC threads, so fixing it inside the helper covers the whole class rather than the one call path that surfaced it.

Also in this PR

profile_name was never passed. _insert_session_row has always accepted it; this caller never sent it. The agent backfills it on its first turn, so an unattributed row is usually only briefly wrong — but a session whose turn never runs (a spawn that dies before its first prompt) keeps a NULL profile_name forever. "default" maps to NULL, mirroring the agent's own normalization so the two writers cannot disagree under COALESCE.

Sibling mis-binding, same root cause. session.create and both lazy-resume responses computed profile_name (and their model fallback) with nothing bound, while the deferred build — the one caller that does bind the home — computed them correctly. A client creating a session under profile: "worker" was told "launcher", then watched both fields flip when session.info landed. _session_info now resolves the name from the session record instead of the ambient home, which fixes it at all ~28 call sites rather than one; _lazy_resume_info takes the home explicitly.

Evidence

Two rows in a real meshboard-game-dev profile db, from sessions whose turn never ran:

model_config.provider	profile_name
ai-router (the root profile's provider)	NULL

Healthy rows in the same db carry meshboard-qualified-local and meshboard-game-dev. The provider on those two rows came from the client's composer pick (a separate, desktop-side concern), but the NULL profile_name is this PR's second half, and it is what makes such a row permanently unattributed.

Note for anyone re-checking that db: both profiles happen to name the same default model, so the model column alone does not discriminate. The model half of the defect is proven by the tests below, not by those rows.

Verification

Real temp profiles, no mocks — added to tests/test_profile_isolation_runtime.py, whose existing brief is exactly this bug class. Two on-disk profiles whose config.yaml name different defaults, driven through the real _ensure_session_db_row, real SessionDB, and the real session.create RPC.

On the parent commit, 5 of the 6 new tests fail:

assert 'launcher/model-A' == 'worker/model-B'
assert 'launcher' == 'worker'

The sixth (test_explicit_composer_pick_still_wins) guards the existing anti-race behavior and passes on both — that is the point of it.

With the fix: 6/6 pass. Wider run of tests/test_tui_gateway_server.py tests/tui_gateway/ tests/test_profile_isolation_runtime.py gives 876 passed, 4 failed — the same 4 failures the parent commit produces on this machine (pre-existing, host-config-dependent), so no regressions. tests/hermes_state/ + related session suites: 513 passed.

Risk

Low. No change to the system prompt, message alternation, or anything cached per conversation. A session with no profile_home (the ordinary local path) resolves exactly as before — _profile_home_bound(None) is a no-op. The behavior change is confined to sessions that already carry a foreign profile home, where the previous value was wrong.