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/Cargo.toml

@@ -21,6 +21,14 @@ wdk-sys = "0.5.1"
 wdk-build = "0.5.1"
 pf-vdisplay-proto = { path = "../../../crates/pf-vdisplay-proto" }
 
+# Vendored windows-drivers-rs 0.5.1 (the published, self-contained crates) + an added `iddcx`
+# ApiSubset (M1 — bindgens iddcx/1.10/IddCx.h reusing wdk_default for WDF type-identity). Redirect ALL
+# wdk-sys/wdk-build refs (incl. wdk 0.4.1's transitive deps) to the patched copies so there is exactly
+# one (iddcx-capable) wdk-sys in the graph. Pinned; do not chase upstream.
+[patch.crates-io]
+wdk-build = { path = "vendor/wdk-build" }
+wdk-sys = { path = "vendor/wdk-sys" }
+
 # wdk-sys's build script reads the WDK driver-model from the WORKSPACE metadata (a workspace build can't
 # know which member it's building for). All our drivers are UMDF 2.x (incl. pf-vdisplay's IddCx), so set
 # it once here; a member needing a different model would get its own [package.metadata.wdk.driver-model].