[CI] Parity: discover job topology from workflow YAML

[ethanwee1]

Summary

• download workflow YAML from raw.githubusercontent.com at the exact tested commit and read CUDA/ROCm num_shards values from the authoritative test matrix
• follow nested reusable workflows and build-job matrix outputs, while retaining configured counts only as a failure fallback
• self-heal renamed job prefixes and redirect artifact downloads to the workflow run that actually hosted reusable-workflow shards

Why parity_job_config.json remains

The workflow YAML is now authoritative for shard counts, but the JSON still supplies information that cannot yet be discovered from one resolved workflow file: the ordered workflow candidates and architecture-specific fallbacks, seed job prefixes used to locate the right family before self-healing, CUDA test-job kinds, and check-run/workflow regexes used by parity-auto.yml before dispatch. Removing the file now would require moving those hardcoded values elsewhere or separately redesigning workflow discovery and gating; it would not actually remove the configuration. A follow-up can remove the JSON once those remaining consumers derive their topology dynamically.

Test plan

• Validate CUDA trunk default (14) and distributed (10) against live workflow source
• Validate ROCm mi300 default (8) and sandbox inductor (4)
• Validate nested CUDA inductor workflow resolution (2)
• Run Python syntax and whitespace checks

[jithunnair-amd]

Can we confirm that the job_key will have the value linux-jammy-rocm-py3_10-build and not linux-jammy-rocm-py3.10-mi350 in trunk.yml?