Fix set() for global scope not updating globalEnv in memory

[StellaHuang95]

Part of #1454

Bug

When a user selects a conda environment as the global Python interpreter, CondaEnvManager.set(undefined, environment) persists the selection to disk via setCondaForGlobal(), but never updates this.globalEnv in memory. Subsequent calls to get(undefined) return the stale old environment because get() returns this.globalEnv directly (line 305).

Why it's a bug

The orchestrator's getEnvironment() method calls manager.get(scope), which returns the in-memory this.globalEnv. Since the field is never updated after set(), the persisted selection is effectively invisible until VS Code is restarted (when loadEnvMap re-reads from persistent state). This causes the selection to appear to "revert" or "flicker" back to the previous environment.

Repro steps

1. Open VS Code with no workspace folders (so the scope is global).
2. Select a conda environment as the Python interpreter.
3. The status bar briefly shows the new environment (from the orchestrator's event), but any subsequent query for the active environment returns the old environment.
4. The selection appears to revert on its own.

Fix

Update this.globalEnv in memory before persisting to disk, matching the pattern already used by venvManager.ts (lines 407–414):

if (scope === undefined) {
    this.globalEnv = checkedEnv;
    await setCondaForGlobal(checkedEnv?.environmentPath?.fsPath);
}

Before:

After:

Why this fix is correct

• The venv manager already uses this pattern and works correctly.
• The checkedEnv variable already accounts for no-python environments (it's undefined if the user declines Python installation), so setting this.globalEnv = checkedEnv correctly handles both the set and unset cases.
• No downstream code assumes globalEnv is only updated during initialization.

Tests added

• condaEnvManager.setGlobal.unit.test.ts: 4 test cases covering set, persist, clear, and no-python decline scenarios.