Add --export-type (generic | optimized) selector to winml build

[DingmaomaoBJTU]

Closes #1090.

Summary

Replaces the implicit device+ep auto-routing to the onnxruntime-genai bundle with an explicit --export-type selector on winml build, so choosing between a stock ONNX export and a runtime-optimized bundle is a deliberate, discoverable decision instead of a side effect of --ep qnn + NPU.

--export-type	Result
generic (default)	Stock single/composite ONNX build (unchanged).
optimized	The family's registered runtime-optimized recipe — today the onnxruntime-genai NPU bundle.

Behavior

• optimized infers the target. The recipe declares its supported_targets ((ep, device) pairs), so --ep/--device are optional; the first target is inferred (Qwen3 → qnn/npu). Building a bundle is hardware-independent, so this path does not probe the local device.
• Fail-fast, no silent fallback. optimized errors when the family has no recipe, the input is a pre-exported .onnx, it is module mode, or an explicitly pinned --ep/--device contradicts the recipe.
• Backward compatible. When --export-type is omitted, the existing shortcut still applies: a registered family with an explicit --ep qnn on an NPU target (--device npu, or --device auto resolving to the NPU) routes to its bundle. --export-type generic always forces the stock build, even on the NPU.

Changes

• Recipe data model (genai_bundle.py): new GenaiTarget frozen dataclass and a required supported_targets field on GenaiBundleRecipe, validated (non-empty) at registration. New symbols exported from the package __init__.
• Qwen3 recipe: declares supported_targets=(GenaiTarget(ep="qnn", device="npu"),).
• winml build (build.py): adds the --export-type choice option and refactors the routing into small helpers (_resolve_genai_recipe, _resolve_optimized_target, _maybe_build_genai_bundle) that keep the switch data-driven and architecture-agnostic.
• Docs: docs/commands/build.md (flag row + reframed genai-bundle section) and docs/samples/qwen3-genai-bundle.md now lead with --export-type optimized and document the shortcut as backward-compatible.

Sample

Build the optimized onnxruntime-genai NPU bundle for a decoder LLM (the target is inferred from the recipe, so --ep/--device are optional):

winml build -m Qwen/Qwen3-0.6B -o out/ --export-type optimized

Force a stock ONNX build instead:

winml build -m Qwen/Qwen3-0.6B -o out/ --export-type generic

The selector is discoverable in --help:

--export-type [generic|optimized]
                                Output selector. 'generic' builds the stock
                                single/composite ONNX model. 'optimized'
                                builds the registered runtime-optimized recipe
                                for the family (today: the onnxruntime-genai
                                NPU bundle); it infers the recipe's target and
                                errors if the family has no recipe or
                                --ep/--device contradicts it. ...

Fail-fast validation when the model type has no optimized recipe (verified in terminal):

$ winml build -m microsoft/resnet-50 -o out --export-type optimized
Error: --export-type optimized: no optimized recipe is registered for model type 'resnet'.

Tests

New CLI routing tests (infer-and-build, generic forces stock, unregistered-family error) plus focused unit tests for target inference/contradiction and the optimized preconditions; registry tests for the empty-supported_targets guard. The genai build/routing suites (tests/unit/commands/test_build_genai_bundle.py and tests/unit/models/winml/) pass; ruff check and strict mypy clean.

[xieofxie]

This optimized path is still reached only after the earlier if ep is None: resolve_check_device_ep(...) block has run. That means winml build -m Qwen/Qwen3-0.6B -o out --export-type optimized still probes local hardware and can fail before the recipe target is inferred, which contradicts the new contract/docs that optimized builds are hardware-independent and don't require detecting the NPU locally. Can we route explicit --export-type optimized before auto-resolving device/EP, or skip that resolution when the optimized target will be inferred from the recipe?

[DingmaomaoBJTU]

Good catch — fixed in ffc3af9. --export-type optimized now skips the resolve_check_device_ep auto-EP probe entirely: the optimized branch resolves (ep, device) from the recipe via _resolve_optimized_target, so the build no longer depends on detecting the accelerator locally. Added a regression test that makes resolve_check_device_ep raise and asserts the bundle still builds (and the probe is not called).

[xieofxie]

For your description

Build the optimized onnxruntime-genai NPU bundle for a decoder LLM (the target is inferred from the recipe, so --ep/--device are optional):

If it is the case, I suggest we resolve first and then error that the --export-type is not supported for ep=xx, device=xx

Infer target from recipe is bad due to

1. conflict with ep device flags resolving
2. if we have more optimized recipes, it is hard to resolve