update precedence on exp #26224

The intended precedence should be:

explicit user/workspace/folder setting
    ?? experiment treatment
    ?? true

So:

Likely changes needed

1. Change the Python extension’s registered default to true

In microsoft/vscode-python/package.json:

"python.useEnvironmentsExtension": {
    "default": true,
    ...
}

Because the setting is tagged onExP, a valid experiment treatment can still replace that default. If experimentation is disabled, telemetry prevents assignment, or the treatment is unavailable, VS Code falls back to the manifest default—now true.

An explicit user/workspace/folder setting remains higher precedence than both the experiment and manifest default.

2. Make Python Environments consume the effective value

The current activation logic in activate deliberately ignores defaultValue and disables only for an explicitly configured false.

After the Python extension’s manifest default becomes true, this repository should instead use the effective configuration value:

const enabled = getConfiguration('python', resource).get<boolean>('useEnvironmentsExtension') ?? true;

That produces the same result for:

• Manifest fallback true
• Valid experiment treatment true or false
• Explicit setting true or false
• Python extension not installed, where the setting may be undefined

The multi-root workspace handling still needs to be retained and should follow normal folder → workspace → user precedence.

3. Keep all UI and activation surfaces aligned

Changing only Python extension activation logic would be insufficient. These must agree on the same effective result:

• Legacy environment-management activation in the Python extension
• Python Environments extension activation
• Commands and views controlled by when clauses in package.json
• Extension installation/enablement logic

Otherwise both implementations could activate, or Python Environments could activate with its UI hidden—the problems described in #1778 and #1892.

The existing config.python.useEnvironmentsExtension != false clauses are problematic when the setting is completely unregistered. A context key derived from the final activation decision would be more reliable for standalone Python Environments usage.

4. Add tests for the full decision matrix

At minimum:

• Explicit true wins over experiment false
• Explicit false wins over experiment true
• Unset + experiment true enables
• Unset + experiment false disables
• Unset + experiment unavailable enables
• Unset + experiments disabled enables
• Unset + telemetry disabled enables
• Python extension not installed enables Python Environments
• Multi-root setting precedence behaves consistently
• Exactly one extension owns environment management in every case

So the central change is fairly small—make the manifest fallback true—but it should be paired with consuming the effective value consistently in this repository and fixing the contribution visibility path.