feat: extend the fused low-precision path to the Metal target

[inureyes]

Part of #570

Summary

Bring the #574 fused low-precision path to the Metal target (via the source-built Metal runtime from #571), validate token-exact-or-within-gate, and measure. This confirms the ADR 0004 transferability thesis: the same graph-level lever lands on a different IREE target without per-backend kernel authoring.

Scope

• Build / link the xla-iree crate against the source-built Metal runtime from build: Makefile targets to source-build the IREE runtime (CUDA + Metal) #571 (make iree-metal).
• Run the track(upstream-iree): fused dequant->matmul for the packed int8 bandwidth win #574 fused low-precision graphs (f16-resident + fused quantized-matmul) through the Metal HAL driver.
• Validate correctness against the f32 path and measure tok/s on Metal.

Integration / acceptance

• The Metal xla-iree build runs the fused low-precision graphs through the normal load / serve path (not an isolated benchmark harness).
• Token-exact or within-gate versus the f32 path per the test: precision accuracy gate and per-device default precision for the OpenXLA backend (#449) #515 accuracy harness.
• Measured faster than f32 on Metal, confirming the ADR 0004 transferability thesis (same graph-level lever, different target).
• Any Metal-specific divergence from the CUDA result (dispatch behavior, precision) is documented.

Dependencies

Depends on #574 (the fused low-precision path this issue transfers to Metal).

[inureyes]

Deferred

This issue transfers the #574 fused low-precision path to the Metal target. Two blockers:

1. spike: quantized-matmul / dequant-to-matmul fusion investigation on IREE (CUDA first) #573 concluded the fused dequant then matmul is upstream IREE work (not achievable in-tree on CUDA, and the same codegen gap applies to Metal), so there is no fused path to transfer yet.
2. Metal validation needs an Apple-Silicon host; the epic work ran on GB10 (Linux/CUDA).

The transferable graph-level lever that IS realized, f16-resident weights (#572), already applies to every IREE target including Metal through the same emitter, so the ADR 0004 transferability thesis holds for it. Deferring this issue to a macOS session and to when upstream IREE lands the fused CUDA/Metal quantized-matmul.

[inureyes]

Done in #611.

On Metal (M1 Ultra, Llama-3.2-1B 4-bit, normal mlxcel generate path):

precision	tok/s (median-3)	vs f32	token-exact vs f32
f32	1.51	1.0x	reference
f16-resident (#572, metal default)	3.45	2.28x	PASS (64 steps)
bf16	n/a	n/a	fails to compile on metal-spirv
packed int8 (#568)	n/a	n/a	prefill invoke faults (IREE INTERNAL)

f16-resident is 2.28x over f32 and token-exact for 64 greedy steps versus the f32 path per the #515 harness, so ADR 0004's transferability thesis holds on a second IREE target with no per-backend kernel work. bf16 does not lower on metal-spirv (the Metal GPU target has no bf16 compute). The packed int8 path compiles but the prefill invoke faults, and its bandwidth win is un-demonstrable on the compute-bound Metal decode regardless.

The fused quantized-matmul this issue set out to transfer does not exist in-tree (upstream IREE work, #573); it stays tracked by #574. Closing #575 on the realizable Metal scope. Full write-up plus the oracle-free xla_traj_dump gate are in #611 and ADR 0004.