feat(windows-drivers): pf-vdisplay STEP 2 — IddCx device skeleton

DriverEntry -> driver_add builds the full IDD_CX_CLIENT_CONFIG (14 IddCx callbacks +
PnP EvtDeviceD0Entry, all stubs with correct PFN signatures) sized via the ported
IDD_STRUCTURE_SIZE! (size.rs), runs IddCxDeviceInitConfig -> WdfDeviceCreate ->
WdfDeviceCreateDeviceInterface(the owned pf-vdisplay GUID, not SudoVDA) ->
IddCxDeviceInitialize. callbacks.rs has all 14 + device_d0_entry; query_target_info
implements HIGH_COLOR_SPACE. edid.rs salvaged verbatim from the oracle. proto gains
interface_guid_fields() (u128 -> Windows GUID fields). Links IddCxStub (the CI gate);
adapter/monitor/swapchain/IDD-push fill the stubs in STEP 3-6.

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

crates/pf-vdisplay-proto/src/lib.rs

@@ -25,6 +25,22 @@ extern crate alloc;
 /// `GUID::from_u128(PF_VDISPLAY_INTERFACE_GUID_U128)`.
 pub const PF_VDISPLAY_INTERFACE_GUID_U128: u128 = 0x7066_7664_7044_5350_a1b2_c3d4_e5f6_0001;
 
+/// The interface GUID split into Windows `GUID` fields — `(Data1, Data2, Data3, Data4)` — so the driver
+/// (and host) can build a `windows`/`wdk_sys` `GUID` without re-deriving the byte layout. Standard GUID
+/// layout from the u128: `Data1` = high 32 bits, `Data2`/`Data3` = next two 16-bit groups, `Data4` =
+/// the low 64 bits big-endian. (This crate is `no_std` + provider-agnostic, so it returns the fields
+/// rather than depend on a `GUID` type.)
+#[must_use]
+pub const fn interface_guid_fields() -> (u32, u16, u16, [u8; 8]) {
+    let g = PF_VDISPLAY_INTERFACE_GUID_U128;
+    (
+        (g >> 96) as u32,
+        (g >> 80) as u16,
+        (g >> 64) as u16,
+        (g as u64).to_be_bytes(),
+    )
+}
+
 /// Bumped on any incompatible change to either plane. Exchanged via [`control::IOCTL_GET_INFO`]; host
 /// and driver assert a match at startup so a mismatched pair fails loudly instead of corrupting.
 pub const PROTOCOL_VERSION: u32 = 1;