e2e_eval: record the precision the build actually applied

[KayMKM]

Problem

run_eval wrote EvalJob.precision — the declared precision — into eval_result.json. That value is None for any winml config fallback job that pins no precision, but such a build is not precision-less: winml config resolves auto to the device default, which on NPU is w8a16.

So a --device npu (pre-#1163) or --device auto --ep <npu ep> run produced a w8a16 QDQ model while the result recorded no precision at all, and the result dir carried no __<precision> suffix. The downstream coverage report maps a missing precision to the unquantized label, so those quantized runs were published as unquantized baselines — models that never had an unquantized NPU run showed a PASS "unquantized" row.

Verified against the published data: openai__clip-vit-base-patch32__zero-shot-image-classification (no suffix, no precision field) has onnx_size_bytes = 178,466,841 ≈ 2 × the model's w8a16 artifact (89.6 MB), vs 253.9 MB for its fp16 build — i.e. the "unquantized" cell is a quantized run.

Change

• _run_build reports the effective precision back to the caller: the pinned --precision flag when there is one, otherwise read from the generated build config's quant section (weight_type/activation_type bit widths -> w{x}a{y}, mode="fp16" -> fp16, mode="rtn" -> int{bits}). Reading the config back is what winml config actually decided, so the harness never has to re-implement the CLI's precision policy.
• Only what the config states is reported: a config with no quant stage yields no precision (unchanged from today), since "winml skipped quantization" is not a claim about the graph's dtype.
• _run_recipe_build reports its authored variant precision.
• main() writes that effective precision into eval_result.json (including the accuracy-backfill merge, which rebuilds the model).

The job's declared precision still drives the result-dir slug and the log label, so folder naming, --continue resume and the existing data layout are unchanged.

Verification

Ran the harness on prajjwal1/bert-tiny (perf only):

run	result dir	recorded precision	onnx_size_bytes
--device cpu	…__feature-extraction	(absent — config has no quant stage)	17,507,493
--device auto --ep openvino	…__feature-extraction	w8a16	8,465,338
--device npu --ep openvino	…__feature-extraction__w8a8	w8a8 (pinned)	4,489,977
--device npu --ep openvino	…__feature-extraction__w8a16	w8a16 (pinned)	4,489,977

The second row is exactly the previously-broken case: same untagged folder, but the generated config is weight_type=uint8, activation_type=uint16 and the artifact is half the size. Before this change that file carried no precision at all.

Recipe path (microsoft/resnet-18, which has fp16 + w8a16 recipes) records fp16 / w8a16 from the variant, as it already did.

Note the real config uses quant.mode = "static", not "qdq", which is why the mapping keys off the weight/activation bit widths rather than the mode.

uv run --no-sync pytest tests/unit/eval -> 540 passed.

[DingmaomaoBJTU]

LGTM. Fixes precision reporting so auto-resolved quantization (e.g. NPU -> w8a16) is faithfully recorded instead of appearing as 'no precision'. Clean extraction of _merge_backfill_result, proper stale-precision cleanup, and comprehensive test coverage.