fix: build std.compat with Clang and MSVC STL

[julixian]

Clang builds using MSVC STL fail on import std.compat because sysroot binding leaves its source unset and the compat precompile command does not recognize MSVC's .ixx extension.

Bind std.compat.ixx alongside std.ixx from the selected MSVC toolset, clearing the compat source when unavailable. Apply -x c++-module only to .ixx source precompilation; BMI code generation and libc++ .cppm input retain their existing behavior. Both commands continue to use the requested language standard and CRT flags.

Closes #768

Validation

• Built mcpp with LLVM 22.1.8 after rebasing onto current main.
• Focused unit/test_toolchain_stdmod tests passed with the freshly built binary.
• A real Windows import std.compat executable built and ran with LLVM 22.1.8 and MSVC STL 14.44.35207 / 14.51.36231, exercising ::malloc, ::free, ::printf, and std::vector.
• An unmodified native MSVC build of the same executable passed.
• Regression coverage checks that .ixx receives the module language override only during source parsing, .cppm receives no override, and std BMI / CRT flags reach both commands.
• git diff --check passed. Full platform coverage is left to CI.

[Sunrisepeak]

LGTM. Binds std.compat.ixx from the same MSVC toolset as std.ixx (also covers the default msvc@system row), and applies -x c++-module only to the source precompile, never to the BMI codegen; the unit test pins both. CI is green.

Follow-ups tracked separately (non-blocking):

• ensure_built builds std.compat whenever a compat source exists, so every clang + MSVC STL import std build now also compiles std.compat.ixx; consider building it only when a unit imports it.
• A Windows e2e for llvm + MSVC STL import std.compat (the canary from #768) so SPEC-009 §6.2's acceptance is enforced in CI.