Add positron.workspace.registerConfigurationMigrations extension API

[samclark2015]

Summary

Adds positron.workspace.registerConfigurationMigrations to the Positron extension API, allowing extensions to declaratively migrate configuration keys they previously contributed.

Each ConfigurationMigrationSpec specifies a source key and destination key. The main thread validates ownership — the requesting extension must have contributed the source key, unless its publisher appears in product.trustedExtensionPublishers — then registers the migration with the internal ConfigurationMigrationRegistry, which handles user/workspace/folder scopes and language overrides automatically.

Also fixes a latent bug: ConfigurationMigrationRegistry.registerConfigurationMigrations was not firing its onDidRegisterConfigurationMigration event, so ConfigurationMigrationWorkbenchContribution never processed migrations registered after workbench init.

Usage:

import * as positron from 'positron';

positron.workspace.registerConfigurationMigrations([{
    key: 'positron.assistant.consoleActions.enable',
    migrateTo: 'console.assistantActions.enabled',
}]);

Release Notes

New Features

• Added positron.workspace.registerConfigurationMigrations API for extensions to migrate legacy configuration keys (Spike: Investigate extension API for migrating configuration keys #14299)

Bug Fixes

• N/A

Validation Steps

1. In a Positron extension, call positron.workspace.registerConfigurationMigrations([{ key: 'old.key', migrateTo: 'new.key' }])
2. Set old.key to a non-default value in user settings
3. Activate the extension and verify the value is copied to new.key and old.key is cleared
4. Verify a non-trusted extension attempting to migrate a key it doesn't own logs a warning and is rejected (probably impractical as all our extensions are trusted)

[github-actions]

E2E Tests 🚀
This PR will run tests tagged with: @:critical

Note

No feature tags detected. If this PR needs feature coverage, add the tag above and retrigger the workflow.

^{readme  valid tags  why these tags?}

[github-actions]

PETE's assessment 🧪

Verdict: 🟢 Adequate -- Every substantive source change is covered: the Mocha test exercises all five ownership branches of $registerConfigurationMigrations, and the Vitest pins the event-firing bug fix.

What changed

• Adds the positron.workspace.registerConfigurationMigrations extension API: ext-host stub forwards to the main thread, which validates source-key ownership (registered-owner, namespace-owner, or posit-trusted bypass) before registering migrations with the internal ConfigurationMigrationRegistry.
• Fixes a latent bug in ConfigurationMigrationRegistry.registerConfigurationMigrations -- it now fires onDidRegisterConfigurationMigration so dynamically-registered migrations are processed.
• Plus the .d.ts API declaration and protocol/ext-host plumbing (no independent logic).

Tests in this PR

• Unit (Vitest/Mocha) ✅ (added mainThreadConfiguration.test.ts cases + configuration.vitest.ts)
• Extension host ✅ (not applicable -- ownership logic lives in the main thread, testable without an activated ext host)
• E2E (Playwright) ✅ (not applicable -- no user-visible rendered workflow; the API is invoked programmatically)

Existing coverage

The new tests are the primary coverage:

• src/vs/workbench/api/test/browser/mainThreadConfiguration.test.ts -- covers owned-key acceptance + migrateFn value mapping, unowned-key rejection + warning, posit-publisher bypass, namespace ownership for an unregistered (renamed) key, and rejection of an unregistered key outside the namespace. This maps 1:1 to every branch in the approved.filter(...) logic.
• src/vs/workbench/common/test/configuration.vitest.ts -- asserts onDidRegisterConfigurationMigration fires on registration, pinning the bug fix in place.

Suggested additions

None.

Deployment note (optional)

N/A -- the change is platform-agnostic main-thread/ext-host logic with no browser//electron-sandbox/ split, path/process/filesystem handling, or UIKind/isWeb branching.

---

PETE (Positron Extreme Test Experiment) - LLM-based test-coverage advisor, in pilot. Triggers on PR open and on /recheck-tests comments. Wrong verdict? Comment /recheck-tests (or /rePETE) on this PR to re-run. Please share feedback on how PETE performed here.

[samclark2015]

/repete

[melissa-barca]

Your PR description says this will be controlled by product.trustedExtensionPublishers, I'm curious what your reasoning was for removing that to hardcoding it? Can we also add rstudio as trusted - this is unfortunately still the publisher of the workbench extension.

[samclark2015]

I had done this initially, but wound up hard-coding due to concerns about side effects. It looks like this will also suppress the “Do you trust publisher X?” for Posit & RStudio if we add this. That sounds reasonable to me, thoughts?

[melissa-barca]

That's a win!