[Feature]: Expose the existing per-project default provider in Project settings

[marcob896]

Before submitting

• I searched existing issues and did not find a duplicate that covers this project-scoped, multi-instance use case.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

T3 already supports multiple instances of the same provider, which is useful for keeping work and personal subscriptions or account contexts separate.

However, there is currently no UI to assign a default provider instance to an existing project. The composer remembers the last active provider, but that preference follows the user's recent activity rather than the project. When switching from a personal repository to a work repository, a new thread can therefore start with the personal provider instance unless the user notices and changes it manually.

This is particularly error-prone because both instances use the same provider driver and may expose the same models. The mistake may only become obvious after the thread has already started under the wrong account context.

The underlying project-scoped capability already exists on current main:

• projects persist defaultModelSelection;
• project.meta.update accepts defaultModelSelection;
• draft and thread creation already consume the project's default selection;
• the web sidebar already has a Project settings dialog;
• provider instances already have stable instance IDs and display names.

The missing piece appears to be only the UI that updates the existing project field.

Proposed solution

Add a Default provider and model control to the existing Project settings dialog for each environment-local project entry.

The control would:

1. list enabled provider instances using their configured display names;
2. allow selecting the model for that instance;
3. save the resulting ModelSelection through the existing projectEnvironment.update / project.meta.update path;
4. offer a reset option that stores null and falls back to the existing selection behavior;
5. show a clear unavailable state if a previously selected provider instance is later disabled or removed.

New drafts and threads would then inherit the selected provider instance through the behavior that already exists.

Why this matters

Remembering the last selected provider solves the repeated-switching case, but not project isolation. A project default prevents accidental use of a personal account for work or a work account for personal projects.

This matters for cost attribution, subscription limits, organizational boundaries, and simply avoiding the loss of a thread that was started under the wrong provider context.

Smallest useful scope

A focused web change only:

• reuse the existing Project settings dialog;
• reuse existing provider/model picker helpers where practical;
• dispatch the existing project update command;
• add focused behavioral tests;
• include before/after screenshots.

No new server RPC, contract, database migration, or provider adapter behavior should be required. Desktop receives the change through the shared web UI. Mobile already consumes the persisted project default when creating a task; a separate mobile editing surface could remain out of scope unless maintainers want it included.

Related work

• [Feature]: Configurable default provider for new threads #1394 requested a global configurable default and was closed after sticky provider/model selection solved that reporter's repeated-switching case. Sticky selection does not solve switching safely between projects that require different provider instances.
• Add per-project settings  #2567 includes project provider/model settings as part of a much broader 106-file project-settings implementation. This issue proposes extracting only the already-supported default provider/model control as a small, focused contribution if maintainers prefer that scope.

Alternatives considered

• Manually check the provider before every new thread. This is the current workaround and is easy to forget.
• Rely on sticky provider selection. This helps when consecutive threads use the same account, but increases the chance of a mistake when moving between work and personal projects.
• Store account-specific configuration inside each repository. Provider credentials and subscription context are machine/user concerns and should not be committed to project source.

Risks or tradeoffs

• A saved provider instance can later be disabled or deleted. The UI should display that state explicitly and allow reset or replacement.
• Grouped projects can have environment-local entries with different available providers, so the selection should be stored and rendered per environment-local project record, matching the existing project data model.

Contribution

• I would be open to implementing the focused scope after maintainer confirmation.