Adopt the parallel pipeline in vxc (deliberately deferred until the scaling result is established)

vxc runs its own sequential frontend in driver.rs — ModuleLoader, MacroExpander,
build_symbol_map + resolve_names, TypeChecker::new per function, lower_function_to_hir — and
then emits MLIR. The parallel pipeline is a second implementation of the same work, and since hiraditya/Vx.1#311 it
produces the same artifact: MLIR text, byte-identical across thread counts, JIT-checked against the
AST oracle.

Switching vxc over is therefore a small change. It is being deliberately postponed, not
overlooked.

Why postponed

The two questions are independent and mixing them makes both harder to answer:

1. Does the parallel frontend scale, and is it faster than the non-parallel form? — a property of
   the pipeline, measured on a corpus, and the number a paper can carry.
2. Does vxc get faster? — a property of the whole compiler, where the frontend is one term and
   MLIR passes → LLVM → object is the other, unaffected by any of this.

Answering 1 first keeps the measurement about one thing. Answering 2 first would mean every
regression in the shipping compiler competes for attention with the experiment.

What has to be true before this is picked up

• The scaling result is established, including a non-parallel baseline — the same phases with the
  parallelism removed, not the pipeline at one thread, so the parallel machinery's own cost is
  visible rather than charged to both sides.
• hiraditya/Vx.1#312 (deferred anti-scales at 2 threads) is explained.
• The ladder has been rerun on homogeneous cores; the development machine is an Apple M4 (4P + 6E),
  where absolute scaling curves do not survive.

What the switch involves when it happens

• driver.rs does work the pipeline does not: a BFS from the entry module so only reachable
  functions are lowered, a second type-check pass to settle StructInit GIDs against the frozen
  registry, and .vxlib interface merging. The pipeline lowers everything it is given and merges no
  interfaces. Those are behaviour differences, not just orchestration ones.
• The pipeline currently re-lowers monomorphs that the check phase could have lowered (noted in
  hiraditya/Vx.1#311). Worth fixing before it is on the shipping path, since it is duplicated work per compile.
• The decline path: compile_pipeline_mlir returns None for anything outside the flat subset.
  vxc would need to keep driver.rs's AST fallback for exactly those programs.

Related: hiraditya/Vx.1#300 (CGO tracking), hiraditya/Vx.1#311 (codegen on the pipeline), hiraditya/Vx.1#312.

Start with driver.rs and compile_pipeline_mlir, then review hiraditya/Vx.1#311 and #312 to establish the required scaling evidence and explain the anti-scaling result. Done means switching vxc only after the non-parallel baseline and homogeneous-core measurements are established, while preserving reachable-function lowering, interface merging, and the AST fallback for unsupported programs.