Users frequently report that the Python extension's interpreter
picker selects a system or homebrew Python instead of the workspace's
pixi environment, leaving the Mojo extension unable to find an SDK
even when one is installed via `pixi add mojo`. The picker's
heuristics aren't pixi-aware, and asking users to manually select the
right interpreter is fragile.

Add a new pixi-detection step to findActiveSDK, between the monorepo
and Python-extension-fallback steps: iterate the Python extension's
known environments, filter to ones inside the workspace's
`.pixi/envs/`, prefer `default` then alphabetical, and use the first
that contains `share/max/modular.cfg`. New `mojo.preferPixiEnv`
setting (default true) disables the step for users who want the
picker as the authoritative source.

Subscribe to `onDidChangeEnvironments` only while a `.mojo` file is
open and SDK detection has failed; filter the event stream to
in-workspace pixi paths so unrelated envs appearing don't churn
detection. This picks up `pixi add mojo` mid-session without
requiring a window reload.

When the chosen pixi env differs from the Python picker's active
env, the SDK status bar tooltip explains the divergence and points
at the new setting.

While in pyenv.ts, also replace the redundant "Unable to load a
Python environment" toast with the existing status bar surface
(whose tooltip now lists the four detection sources in priority
order), and fix the long-standing "enviroment" typo from #9. Drop
the yellow background from the LSP undefined state and the
no-Python-extension state to reduce visual redundancy when they
coexist with the no-SDK item (which keeps its yellow as the primary
attention signal).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

tryGetPixiSDK reads api.environments.known to find a workspace pixi
env, but that list is populated asynchronously by the Python
extension's scan. The pyenv.test.pixi.ts integration test runs
findActiveSDK immediately after activation, before the scan finishes,
so the pixi env is missing from `known` and detection falls through
to the system Python active env (which has no Mojo). The previous
code worked because it called resolveEnvironment on the active path,
forcing per-env resolution even mid-scan.

Await refreshEnvironments() once in tryInitApi so the scan completes
before any SDK lookup runs against `known`. Per the API docs the call
is a no-op after the first session-level discovery, so this only
adds latency on initial activation.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>