vx check should treat the pinned Rust semver as source of truth, not report it as system_fallback

[loonghao]

Summary

When a project pins Rust as a real semantic version in vx.toml (for example rust = "1.93.1"), that exact Rust version should be the source of truth at the vx configuration/check/lock layer.

It is totally fine for the backend/provider implementation to internally map that version to a rustup-managed toolchain or shim. But if that mapping resolves to the exact requested Rust version, vx check --json should not surface the result as an ambiguous system_fallback state.

Environment

• vx: 0.8.15
• OS: Windows (x86_64-pc-windows-msvc)

Project config

vx.toml:

[tools]
just = "1.48.1"
rust = "1.93.1"
python = "3.11.13"

rust-toolchain.toml:

[toolchain]
channel = "1.93.1"
components = ["cargo", "clippy", "rustfmt"]

Reproduction

1. Run vx sync
2. Run cargo --version
3. Run rustc --version
4. Run vx check --json

Observed

cargo --version returns:

cargo 1.93.1 (083ac5135 2025-12-15)

rustc --version returns:

rustc 1.93.1 (01f6ddf75 2026-02-11)

But vx check --json still reports Rust like this:

{
  "runtime": "rust",
  "required": "1.93.1",
  "installed": null,
  "satisfied": true,
  "status": "system_fallback",
  "path": "C:\\Users\\hallo\\.cargo\\bin\\cargo.exe"
}

Expected

vx should keep the logical contract at the tool level:

• config declares the real Rust version (1.93.1)
• lock/check/reporting should reason about that real Rust version
• backend/provider code may internally map it to rustup toolchains/shims

So if the rustup-backed execution path resolves to the exact requested version, vx check should report that as a managed/resolved match, rather than system_fallback.

At minimum, the current output is misleading because it makes the project look non-reproducible, even though the effective Rust toolchain version is exactly the pinned one.