fix: migrate EPAlias to EPNameOrAlias for better alignment; fix infer_ihv_from_ep_name

[xieofxie]

Summary

Close #646 (migrate EPAlias to EPName where possible). EPNameOrAlias is the public-facing input type; EPName is the internal canonical form. This PR removes places where a bare alias was used where a canonical name belongs, and stops comparing against single alias literals.

Changes

• analyze/utils/ep_utils.py — infer_ihv_from_ep_name now does a direct, exact dict[EPName, IHVType] lookup covering every member of the EPName Literal. An unknown name now raises ValueError instead of silently defaulting to IHVType.MICROSOFT (the callers that matter already handle it: InformationEngine catches ValueError and falls back to loading all rules; the model validator catches it defensively). Also fixes a latent miss where CUDAExecutionProvider resolved to MICROSOFT instead of NVIDIA.
• serve/schema.py — EpSwitchRequest.ep was the only ep field still typed bare EPAlias; every sibling is EPNameOrAlias and manager.switch_ep already accepts EPNameOrAlias. Widened it for consistency so it accepts both "qnn" and "QNNExecutionProvider".
• compiler/utils.py — needs_format_conversion compared ep == "qnn", a single alias literal. An EP can have multiple aliases (e.g. nv_tensorrt_rtx / nvtensorrtrtx), and the canonical name itself wouldn't match. Now normalizes via normalize_ep_name and compares against the canonical "QNNExecutionProvider"; parameter widened to EPNameOrAlias.

Notes

• The compiler's EPConfig.provider deliberately remains alias-typed: every value it holds is an alias (provider="qnn", etc.), so retyping to EPName would require a value migration with serialization back-compat — out of scope here.
• An audit of all ~90 EPNameOrAlias call sites confirmed every one either normalizes before a canonical sink or forwards to a callee that does — no other un-normalized canonical-sink usages were found.

Tests

• Replaced the per-EP infer_ihv unit tests with one that verifies every EP_NAMES member resolves to an IHVType (enforcing map/Literal parity) plus an unknown-raises test.
• Updated fixtures that relied on the old lenient behavior to use canonical EP names (ACEExecutionProvider → VitisAIExecutionProvider; alias "openvino" → "OpenVINOExecutionProvider" in the validator tests).
• Added test_qlinear_for_qnn_canonical_name covering the canonical-name case that previously failed in needs_format_conversion.

[DingmaomaoBJTU]

Reviewed the EPAlias -> EPNameOrAlias migration and the infer_ihv_from_ep_name rework. Overall this is a clean, well-motivated change — the map/Literal-parity test is a nice touch, and catching CUDAExecutionProvider -> NVIDIA (was silently MICROSOFT) is a good latent-bug fix.

One concern about the new raise on unknown EPs and one un-audited caller (output_aggregator.build_ep_support) — left inline. Not necessarily blocking, but worth resolving for consistency with the other two call sites.

[DingmaomaoBJTU]

Re-reviewed the two new commits (use IHVType.UNKNOWN instead of raise, resolve mypy union-attr and assignment narrowing).

My earlier concern is fully resolved. Switching infer_ihv_from_ep_name to return IHVType.UNKNOWN instead of raising makes inference total, so all three call sites — including the previously-unguarded output_aggregator.build_ep_support — are now safe. Verified end to end: UNKNOWN only flows into a debug log there; InformationEngine maps UNKNOWN -> None (loads all rules); the redundant try/except in BatchedConstMatMulValidator is correctly removed since UNKNOWN != INTEL. Tests updated accordingly and CI is green (lint/mypy + all test shards + CodeQL).

Two minor, non-blocking notes:

1. rule_loader.load_runtime_rules(None) iterates for ihv in IHVType, which now includes UNKNOWN, producing one extra No rule files found for Unknown ... skipping warning on the load-all path. It's harmless and exactly mirrors the existing behavior for MICROSOFT (also absent from prefix_map), so no change needed — just flagging that adding an enum member has this ripple effect.

2. models/auto.py is unrelated to the EP migration — it's a legit mypy narrowing fix (_model_type: str | None) bundled into the mypy commit, and it also defers AutoConfig.from_pretrained until there's no explicit model_type override (a small behavioral improvement). Fine to keep; noting it only because it's outside the PR's stated scope.

LGTM from my side.

[DingmaomaoBJTU]

Approving. My earlier concern about the unguarded output_aggregator.build_ep_support caller is fully resolved by making infer_ihv_from_ep_name total (returns IHVType.UNKNOWN instead of raising), which cleanly removes the inconsistency across all three call sites. Verified end to end, and CI is green (lint/mypy + all test shards + CodeQL). The two remaining items I noted (the harmless Unknown warning in rule_loader's load-all path, and the unrelated auto.py mypy fix) are non-blocking.