[Feature]: Make provider and model selection sticky per conversation

[bobo-xxx]

Preflight checklist

• I searched existing issues and discussions and this hasn't been proposed yet.

What problem does this solve?

Open Science should persist the selected provider and model independently for each conversation. Changing the model in Session A should affect only future turns in Session A; Session B should retain its own model across navigation, restart, and resume.

Currently, the provider/model picker appears in the active conversation, but it updates the application's global active provider and model. This makes separate sessions interfere with each other.

Example:

1. Select GPT-5.6 Sol in Session A.
2. Open Session B and select GLM-5.2.
3. Return to Session A and send another message.
4. Session A uses the newer global selection instead of retaining GPT-5.6 Sol.

This is surprising for users who keep multiple research sessions open for different models or providers. Although a session stores agent metadata, its next turn is dispatched using the current global selection rather than a sticky session preference.

Proposed solution

Make the primary provider and model sticky per conversation/session.

Required behavior

• A new session initially copies the current application-default provider and model.
• Each existing session persists its own provider and model.
• Changing the picker in Session A changes only Session A.
• Session B keeps its own selection.
• A session restores its selection after navigation, application restart, and session resume.
• A model change does not interrupt an in-flight turn; it applies to the next turn.
• Global provider/model settings remain the defaults for newly created sessions.
• Older sessions without a stored selection fall back safely to the global defaults.
• Provider credentials and provider definitions remain global; this request only scopes the selected primary provider/model to the session.

Suggested resolution order:

1. Provider/model explicitly selected for the session
2. Provider/model persisted on that session
3. Application default
4. Provider default

The existing session metadata fields such as agentFrameworkId, agentBackendId, and agentModel may provide a migration path, but the exact implementation is left to the maintainers.

Expected behavior

Action	Expected result
Change model in Session A	Future primary-agent turns in A use the new model
Open Session B	B retains its own stored provider/model
Restart Open Science and reopen A	A restores its stored provider/model
Change the application default	Existing sessions are unchanged; new sessions inherit it
Change model during an active response	Current response finishes; the next turn uses the new model

Alternatives considered

• Keep one global active provider/model: simple, but causes cross-session interference.
• Treat the picker as a one-turn override: avoids a global change but is not sticky after navigation or resume.
• Duplicate provider configurations or run multiple application instances: possible workaround, but cumbersome and does not match the session-oriented UI.

Additional context

Claude Science provides a useful behavioral reference: the primary model is stored as a sticky property of the root conversation, while global model configuration acts as a fallback/default. Reopening one conversation restores that conversation's model rather than adopting the model most recently used elsewhere.

The requested isolation boundary is the Open Science conversation/session—not a browser window or an internal branch.

Related but distinct work:

• Headless CLI: remaining headless CLI capabilities (attachments, per-run model/backend selection, npm publication) #363 concerns per-run model/backend selection for the headless CLI.
• fix(acp): isolate sessions across framework switches #376 protects active runtime generations during framework/provider switches, but does not make the selected model a persistent preference of each UI session.

This request intentionally does not include per-session credentials, provider definitions, reasoning effort, reviewer-model selection, or context limits. Those can remain global or be addressed separately.

Alternatives considered

No response

Additional context

No response