Support nextest tooling across native Windows and WSL

Tracking issue: MicroVM support and private snapshot restore.

Motivation

Developers validating Windows and Linux virtualization paths may build natively
or use WSL for cross-compilation. The test runner must be selected and invoked for
the environment in which it executes, with paths and exit status preserved. A
repeatable workflow is needed before expanding the boot and restore test matrix.

Proposed Scope

• Make nextest acquisition and invocation work in supported native Windows and
  WSL workflows.
• Keep the host-tool platform distinct from the target of the tests being built.
• Handle executable naming, working directories, and paths at the Windows/WSL
  boundary through the existing tooling abstractions.
• Preserve profile selection, filters, output, and the runner's failure status.
• Retain cargo xflowey vmm-tests-run as the entry point for VMM tests so artifact
  discovery and environment setup are not bypassed.

Acceptance Criteria

• A scoped unit-test invocation works on native Windows and in the supported
  WSL workflow, including paths containing spaces.
• The selected runner matches its execution environment, independently of the
  test target.
• A deliberate test failure is visible to the caller and produces a failure
  result on both paths.
• The agent profile and test filters reach nextest without being rewritten
  or dropped.
• VMM-test invocations retain artifact handling, and any platform or filesystem
  restrictions are documented and reported clearly.

Dependencies

No feature prerequisites. The Windows validation issue is related infrastructure,
not a runtime dependency.

Non-Goals

This issue does not replace the VMM test runner or require every hypervisor test to
run in an unprivileged hosted environment.