fix(desktop): stop a session's effort and fast mode moving the composer pick

[OmarB97]

What this is

#318 stopped a spawned session's model from overwriting the composer's persisted selection. Reasoning effort and fast mode are sticky in exactly the same way, are read by the same function for the same purpose, and were left with exactly the same bug. This is that fix, applied to the two remaining fields.

I found this while fixing the context meter (#316) and originally wrote the model half too — #318 landed first and did it better, so this keeps only what is still missing and follows #318's pattern rather than competing with it.

The bug

$currentReasoningEffort and $currentFastMode persist to localStorage, and desktopSessionCreateParams reads both as what the next new chat runs. Four paths wrote session runtime values into them using the persisting setters, so whatever session you had open silently became your stored default:

Path	When it fired
syncRuntimeMetadataToView	every state flush of the focused session
applyRuntimeInfo	session create
applyStoredSessionPreviewRuntimeInfo	sidebar preview of a stored session
session.info handler in gateway-event.ts	every heartbeat

The last one deserves a look. It sits inside the if (apply) block whose own comment explains why model/provider must not be written there — the guard was placed and then walked around by the lines below it. And apply is also true for a global broadcast when no session is active, so a heartbeat could rewrite the user's stored effort while they sat on a fresh draft, with nothing on screen to explain it.

The fix

Straight from #318: $activeSessionReasoningEffort / $activeSessionFastMode hold what the open session runs (unpersisted, null = no session owns the display), $primaryReasoningEffort / $primaryFastMode compute live ?? picked for the primary chat surface, and session-view.tsx displays those. Only a deliberate pick — model menu, presets, Settings — or the profile-default seed still writes $currentReasoningEffort / $currentFastMode.

clearActiveSessionModel became clearActiveSessionRuntime, since it now hands back all four mirrors. desktopSessionCreateParams is untouched and still reads the stored pick, which is the point.

One thing to check me on

Two existing assertions in use-session-state-cache.test.tsx moved from $currentReasoningEffort to $primaryReasoningEffort. That is not a failing test being edited into submission: those assertions test what the composer displays, and the atom holding that answer changed identity — the identical edit #318 made to the model assertions sitting beside them. Their meaning is unchanged, and the test still proves a background session's metadata does not paint the foreground.

Evidence

Proven both directions rather than assumed:

• Revert only the use-session-state-cache.ts swap → 3 tests fail (expected 'high' to be 'low').
• Revert only the gateway-event.ts swap → 2 tests fail (expected 'low' to be 'high').
• End to end: with a stored pick of effort=high / fast=true, after a session reporting low / false, the next chat's session.create params still carry reasoning_effort: 'high' and fast: true.

Checks

• npm run test:ui — 1954 passed, 1 skipped, 0 failures (rebased onto fix(goals): make the goal store's launch-home scope deliberate, not accidental #320).
• npm run typecheck (app + electron + e2e) — clean.
• npx eslint src/ electron/ — 9 errors, matching the pre-existing baseline on main exactly; both errors in files this PR touches were confirmed via git stash to pre-date it.
• Playwright e2e — 18 passed.

🤖 Generated with Claude Code