Fix fp16 quantization name collision

[Zhenchao Ni (zhenchaoni)]

Problem

ORT’s FP16 converter generates deterministic I/O Cast names when preserving FP32 public I/O. Existing models, including the Affinity encoder and decoder, may already contain these names. Our collision guard consequently rejects conversion.

Solution

Add a preprocessing step that renames conflicting internal tensors and nodes before calling ORT:

• Use inferred I/O types to identify the exact names ORT will generate.
• Allocate deterministic __existing_N names, avoiding existing and newly allocated names.
• Update tensor references and metadata, including nested captures, while respecting local scope.
• Preserve public I/O names and types, and leave conversion-neutral nodes unchanged.
• Retain the existing collision guard as a safety check.

This change only resolves naming conflicts; it does not change precision-conversion policy or prevent ORT from adding Casts during repeated conversion.

[Qiong Wu (qiowu) (DingmaomaoBJTU)]

Reviewed the collision preprocessing and its integration. The standalone FP16 test module passed all 148 tests with ONNX 1.18 and ORT 1.30 (outside the repository-wide conftest/native EP setup). A separate reproduction identified the failure-path mutation below; no product files were changed.

[Qiong Wu (qiowu) (DingmaomaoBJTU)]

Re-reviewed the update since 35d04da. The previous failure-path mutation finding is addressed: keep-I/O preprocessing and conversion operate on a copy, and the caller model is updated only after successful validation. The original unloaded-external-weight reproduction now leaves the caller model byte-for-byte unchanged. All 149 standalone FP16 tests passed locally with ONNX 1.18 / ORT 1.30, outside the repository-wide conftest, and diff checking passed. No remaining blocking findings. CI optim/models/CLA checks have passed; other CI jobs are still pending at review time, so this approval does not assert a fully green CI run.