Add PF_ARM_V82_FHM and PF_ARM_V83_FCMA to PROCESSOR_FEATURE_ID / IsProcessorFeaturePresent

## Request

Please add two new `PF_ARM_*` constants to the `IsProcessorFeaturePresent` API surface and the `PROCESSOR_FEATURE_ID` metadata enum:

- `PF_ARM_V82_FHM` — FEAT_FHM, FP16 Fused Multiply Add (FMLAL/FMLSL), ARMv8.4 mandatory
- `PF_ARM_V83_FCMA` — FEAT_FCMA, Floating-point Complex Multiply Add (FCMLA/FCADD), ARMv8.3 mandatory

## Why these two specifically

Both are **mandatory** on every Windows-on-ARM CPU shipped to date (Microsoft SQ1/SQ2/SQ3, Snapdragon 8cx Gen 1/2/3, Snapdragon X Elite/Plus). There is no Windows ARM64 device in the field that lacks them, yet user-mode code currently has no Win32 way to confirm their presence — every other feature at comparable architecture level is now exposed.

The recent expansion in MicrosoftDocs/sdk-api#2140 (Dec 2025) added 30+ \`PF_ARM_*\` constants spanning SVE, SVE2, SME, SME2, SHA3, SHA512, \`PF_ARM_V82_FP16\`, \`PF_ARM_V82_I8MM\`, \`PF_ARM_V86_BF16\`, etc. FHM and FCMA were the conspicuous omissions in an otherwise thorough sweep.

## Architectural inference doesn't fill the gap

Unlike FEAT_RDM — which can be inferred from FEAT_DotProd or FEAT_LSE via the ARMv8.1 AdvSIMD rule (Arm doc 109697, "The Armv8.1 architecture extension") and is what .NET 10 ships in dotnet/runtime#109493 — there is no equivalent direct architectural implication for FHM or FCMA from any IPFP-visible feature. The closest provable chain (via JSCVT or LRCPC pinning the v8.3-A floor) reaches FCMA but never FHM. Without these two constants, user-mode code on Windows ARM64 must fall back to reading \`HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0\CP \` registry values — workable, but registry access is not always available to sandboxed processes.

## Downstream demand

- Rust's \`is_aarch64_feature_detected!("fhm")\` and \`("fcma")\` currently return \`false\` on Windows ARM64. Recently merged rust-lang/rust#155856 deliberately scoped its IPFP wiring to features Microsoft already exposes; FHM and FCMA were left out for that reason.
- .NET tracking of similar gaps: dotnet/runtime#74778 (resolved once Microsoft added LRCPC/DC ZVA constants), dotnet/runtime#39094, dotnet/runtime#109493.
- Crypto libraries, image codecs, and signal-processing crates that already use FCMA on Linux/macOS ARM64 lose the codepath on Windows.

## Precedent

#1618 covered the \`PROCESSOR_FEATURE_ID\` metadata enum lagging the SDK headers. This request is upstream of that — both the SDK header (\`winnt.h\`) and the metadata enum need the two new values.

Start by locating the Windows SDK winnt.h definitions for PF_ARM_V82_FHM and PF_ARM_V83_FCMA, then find the PROCESSOR_FEATURE_ID metadata enum and review precedent #1618. Done means both constants are represented in the SDK API surface and metadata enum with the requested names and values.

Written by the indexing model from the issue text.