feat(windows-drivers): vendor wdk 0.5.1 + add ApiSubset::Iddcx (M1 spike)

Vendor the published, self-contained windows-drivers-rs 0.5.1 crates
(wdk-build, wdk-sys) under vendor/ and add a first-class ApiSubset::Iddcx that
bindgens iddcx/1.10/IddCx.h in an extra pass reusing bindgen::Builder::wdk_default
(allowlist_file (?i).*iddcx.* — emits only IddCx items; WDF/DXGI types resolve to
the shared base/wdf bindings, type-identity by construction). Mirrors the existing
gpio/hid/spb subsets exactly: wdk-build gets the enum variant + iddcx_headers()
(UMDF-only), wdk-sys gets generate_iddcx + the iddcx feature + pub mod iddcx.
[patch.crates-io] redirects all wdk-sys/wdk-build (incl. wdk 0.4.1 transitive) to
the patched copies. wdk-probe enables the iddcx feature.

MAKE-OR-BREAK: does IddCx.h bindgen in wdk-sys config without a header conflict
(issue #515) + does the generated module compile (type-identity)? CI answers it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

packaging/windows/drivers/wdk-probe/Cargo.toml

@@ -22,5 +22,8 @@ wdk-build.workspace = true
 
 [dependencies]
 wdk.workspace = true
-wdk-sys.workspace = true
+# `iddcx` feature → wdk-sys runs the IddCx bindgen pass (generate_iddcx) + compiles `wdk_sys::iddcx`.
+# This is the M1 make-or-break: does IddCx.h bindgen in wdk-sys's config without a header conflict, and
+# do its WDF/DXGI types resolve to wdk-sys's (so the generated module compiles)?
+wdk-sys = { workspace = true, features = ["iddcx"] }
 pf-vdisplay-proto.workspace = true