Positron Assistant: Control provider list via Settings UI

[jthomasmock]

Currently, we require that new providers are added via positron.assistant.enabledProviders in settings.json. This leads to poor discoverability and also limits how much signaling we can provide to users about ALL providers or nuance about specific providers.

As we move towards stabilizing model provider support, we should add UI that allows users to enable/disable specific providers. This also would allow us to add additional links to documentation, constraints, preview/experimental status, etc.

We could do something like this, where we have Anthropic and Copilot checked by default, and list the rest of the preview providers and have them unchecked by default

Documentation Action Items

• https://github.com/rstudio/rstudio-pro/issues/9939
• Assistant: update docs for provider settings #11563
• Update Positron and Workbench release notes as appropriate

[jthomasmock]

Ultimately, I want to be able to:

1. Indicate what model providers are even possible to use
2. Indicate the status of those providers (GA, Preview, Experimental, etc)
3. Add additional metadata in future.

[sharon-wang]

With this work, let's evaluate whether we can remove the need for users to know the right provider IDs when modifying provider-related settings.

We'll want to look at the positron.assistant.models.* settings from #11096, some of which require knowing provider IDs

#11096 (comment)

I wonder if we want to get to a place where users/admins don't need to know provider ids (which may change, and would result in us having to support migration or them having to update their settings), and we internally map the providers to the right provider IDs?

E.g. in the settings, users just need to know anthropic, openai, etc. and internally we map to anthropic-api, openai-api, etc.

[juliasilge]

In #11470, we have a clear articulation of the use case here, where there is a need to configure different providers at the workspace level.

[juliasilge]

We've got another use case to check for in #11487, where a user needs to have env vars set (like ANTHROPIC_API_KEY) for other, non-Positron-Assistant work but does NOT want to use Anthropic as a provider for Positron Assistant. We'll need to check that this works correctly (can disable a provider even when env vars are set) when verifying this issue.

[timtmok]

This is the code for the AdminPolicyService. It reads the admin config and sets the preference key/value pairs. We can migrate any preferences at this point and it will be set in the configuration service. That will prevent users from changing the values for the new preference keys.

https://github.com/rstudio/vscode-server/blob/main/src/vs/platform/policy/common/adminPolicyService.ts

The changes could probably be made in the Positron code base since it would know the new preference keys.

Admins would still need to update the enforced configuration to the new preferences.