fix avx10 detection under Intel SDE

[abadams]

Claude says:

Host CPU detection (in both src/Target.cpp and the runtime helper
src/runtime/x86_cpu_features.cpp) was checking
CPUID.(EAX=7,ECX=0).EDX[19] to decide whether AVX10 is present. The
AVX10 enumeration bit actually lives at CPUID.(EAX=7,ECX=1).EDX[19]
-- both files had read both sub-leaves into info2 and info3
respectively, so the fix is a one-token change from info2.edx to
info3.edx in each place. The APX detection a few lines below was
already reading info3.edx, which is what tipped me off that the
AVX10 line was a slip rather than an intentional choice.

Why this hadn't surfaced on real silicon, despite being shipped since
early 2024: the bad path requires both os_avx512 to be true AND
CPUID.7.0.EDX[19] to be set on the same CPU. On Intel hardware
through Sapphire Rapids, CPUID.7.0.EDX[19] is reserved and reads as
zero, so the check is harmlessly always false. On hybrid Alder/Raptor
Lake parts various hybrid-related bits in CPUID.7.0.EDX are set,
but those CPUs don't have AVX-512 enabled by the OS, so os_avx512
is false and the outer guard blocks the path. On real Granite Rapids
(the first chip that actually has AVX10) both leaves agree, so the
buggy check happens to give the right answer.

Intel's SDE is what makes the bug visible: under sde -spr, the
emulated CPUID sets CPUID.7.0.EDX = 0xffdc4432 (bit 19 = 1) while
correctly leaving CPUID.7.1.EDX[19] clear, and reports os_avx512.
That combination -- impossible on shipped silicon -- triggers
host-detection to push Target::AVX10_1 even though the chip
doesn't have AVX10. SDE additionally returns
CPUID.24.0.EBX = 0x00000002 (version=2, but all of the 128/256/512
width bits clear), so vector_bits is never set away from its
default of 0, and CodeGen_X86::mattrs() hits
user_error << "AVX10 only supports 256 or 512 bit variants".

The runtime version had the same typo with a milder symptom: it
doesn't track vector_bits, so it would silently advertise
halide_target_feature_avx10_1 as available to anything that calls
halide_can_use_target_features on a machine matching the
SDE-style combination. No shipped Intel part hits this today, but
it's the same latent landmine and worth fixing alongside the JIT
path.

Found while running the correctness suite under SDE for a variety
of Intel microarchitectures, where every chip except -spr passed
cleanly; the 9/10 SPR failures all decoded to this single
detection bug.

Andrew says: I verified this is where LLVM looks for avx10 support in its host detection, so I believe Claude's explanation.

[codecov]

Codecov Report

❌ Patch coverage is 90.62500% with 3 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (main@dd187a2). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
src/CodeGen_X86.cpp	90.62%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #9135   +/-   ##
=======================================
  Coverage        ?   69.80%           
=======================================
  Files           ?      255           
  Lines           ?    77525           
  Branches        ?    18534           
=======================================
  Hits            ?    54120           
  Misses          ?    17948           
  Partials        ?     5457           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[alexreinking]

This needs to be rebased on main.