refactor: rename pf-vdisplay-proto -> pf-driver-proto (it spans all drivers)

The shared host<->driver ABI crate already contains more than the virtual
display: the IDD-push frame ring + control plane AND the gamepad shared-memory
layouts (XusbShm / PadShm). "pf-vdisplay-proto" was a misnomer — the name now
represents all the drivers it serves.

Mechanical rename, no behavior change:
- git mv crates/pf-vdisplay-proto -> crates/pf-driver-proto (package name +
  path-deps in the host crate and the driver workspace).
- pf_vdisplay_proto -> pf_driver_proto across host + driver Rust, both Cargo.lock
  files, the workspace members, the CI path triggers (windows-drivers.yml), and
  the docs/INF comments. The runtime Global\pfvd-* shared-object names are a
  SEPARATE contract and are deliberately untouched (host<->driver name matching).
- The pf-vdisplay DRIVER crate + its INF service name (Root\pf_vdisplay,
  UmdfService=pf_vdisplay, pf_vdisplay.dll) are unchanged — only the full
  `pf_vdisplay_proto` token was replaced, never the `pf_vdisplay` driver name.

Linux-verified: cargo test -p pf-driver-proto (const size-asserts compile) +
cargo clippy -p punktfunk-host -D warnings clean; Cargo.lock regenerated. The
driver-workspace side (path-dep + imports + its Cargo.lock) is Windows-CI-gated.

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

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

@@ -1,6 +1,6 @@
 # M0/M1 toolchain probe: the smallest possible UMDF2 driver on windows-drivers-rs (crates.io wdk 0.5).
 # Purpose: prove on the windows-amd64 runner that (1) wdk-sys bindgen + WDF stub link works against the
-# runner's WDK + LLVM, (2) the shared no_std pf-vdisplay-proto ABI crate path-deps cleanly into a driver
+# runner's WDK + LLVM, (2) the shared no_std pf-driver-proto ABI crate path-deps cleanly into a driver
 # build graph, and (3) what the produced DLL's PE FORCE_INTEGRITY (/INTEGRITYCHECK) bit is. NOT shipped.
 [package]
 name = "wdk-probe"
@@ -26,4 +26,4 @@ wdk.workspace = true
 # 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
+pf-driver-proto.workspace = true

packaging/windows/drivers/wdk-probe/src/lib.rs

@@ -2,7 +2,7 @@
 //! crate's Cargo.toml). DriverEntry → WdfDriverCreate → (EvtDeviceAdd) IddCxDeviceInitConfig →
 //! WdfDeviceCreate → IddCxDeviceInitialize → IddCxAdapterInitAsync: enough to exercise the wdk-sys WDF
 //! stub link AND prove the `iddcx` subset is callable + links against `IddCxStub`. Also force-links the
-//! shared `pf-vdisplay-proto` ABI crate (no_std + bytemuck) across the workspace boundary.
+//! shared `pf-driver-proto` ABI crate (no_std + bytemuck) across the workspace boundary.
 
 #![allow(non_snake_case, clippy::missing_safety_doc)]
 
@@ -18,10 +18,10 @@ use wdk_sys::{
 
 const STATUS_SUCCESS: NTSTATUS = 0;
 
-/// Force `pf-vdisplay-proto` to actually link into the driver build graph (validates the cross-workspace
+/// Force `pf-driver-proto` to actually link into the driver build graph (validates the cross-workspace
 /// path-dep + that the no_std bytemuck ABI crate compiles for a UMDF cdylib). `#[used]` keeps it.
 #[used]
-static PROTO_GUID_LO: u64 = pf_vdisplay_proto::PF_VDISPLAY_INTERFACE_GUID_U128 as u64;
+static PROTO_GUID_LO: u64 = pf_driver_proto::PF_VDISPLAY_INTERFACE_GUID_U128 as u64;
 
 /// IddCx (stub mode) requires the driver to export the minimum IddCx framework version it needs — the
 /// `#ifndef IDD_STUB` branch of `IddCxFuncEnum.h` (which normally emits it) is compiled out under