feat(host/windows): seal the host↔driver channels (frame + gamepad, proto v2)

Frame ring (pf-vdisplay) and both gamepad SHM channels move off named Global\
objects (openable by any sibling LocalService) to UNNAMED sections/events whose
handles the host DuplicateHandles into the driver's verified WUDFHost with least
access — frame delivery over the SYSTEM+admins-only IOCTL_SET_FRAME_CHANNEL,
pads over a 32-byte named bootstrap mailbox (pid + handle value only, DoS-bounded;
HID minidrivers have no control device). Driver-validated pad_index kills
cross-pad redirects; v1↔v2 mixes fail closed with diagnosis logs on both sides.
Sibling-LocalService denial proven empirically (design/idd-push-security.md,
design/gamepad-channel-sealing.md).

Driver-side raw ops now live behind pf-umdf-util (checked shm accessors, the
forbid(unsafe_code) ChannelClient state machine, WDF request tokens) — the pad
drivers' logic is 100% safe Rust; whole drivers workspace clippy-gated in CI.

driver install --gamepad now sweeps SWD\punktfunk phantom devnodes: a re-created
SwDevice REVIVES the old devnode with its previously-bound driver (never
re-ranks), so an upgrade otherwise leaves the old driver serving — or, across
the v1→v2 fence, a dead pad (found live on the RTX box).

On-glass validated on the RTX 4090 box: frame path 7007 frames p50 2.06 ms
cross-machine; DualSense + XUSB "sealed pad channel mapped"/proto=2 attach via
both the test harness and a real streaming session; phantom-sweep repro.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

packaging/windows/drivers/pf-umdf-util/src/lib.rs

@@ -0,0 +1,35 @@
+//! The audited unsafe-primitive layer under the punktfunk UMDF gamepad drivers (`pf-xusb`,
+//! `pf-dualsense`).
+//!
+//! A UMDF driver cannot be literally free of `unsafe` — WDF dispatch, Win32 section mapping and
+//! cross-process shared memory are FFI by nature. What Rust *can* buy is confining every raw
+//! operation to one small, reviewed layer with explicit contracts, so the drivers' business logic
+//! (the sealed-channel state machine, report plumbing, IOCTL policy) is **100 % safe code** and a
+//! memory-safety bug can only live in this crate. Three modules:
+//!
+//! * [`section`] — [`section::MappedView`]: bounds- and alignment-checked access to a mapped shared
+//!   section (atomics for the cross-process sync fields), plus the leaked-view [`section::ViewCell`].
+//! * [`channel`] — [`channel::ChannelClient`]: the sealed pad channel's driver side
+//!   (`design/gamepad-channel-sealing.md`), a **`#[forbid(unsafe_code)]` module** — the entire
+//!   handshake/validation/adoption state machine is safe Rust over [`section`]'s API.
+//! * [`wdf`] — [`wdf::Request`] + queue/device-property helpers: each framework callback converts
+//!   its raw `WDFREQUEST` into a token exactly once (`unsafe`, with the framework's validity as the
+//!   contract); everything after that is safe.
+//!
+//! Lint gates (mirrored in every driver crate, enforced by the drivers CI clippy step):
+//! `unsafe_op_in_unsafe_fn` + `clippy::undocumented_unsafe_blocks` — every remaining `unsafe {}`
+//! must carry a `// SAFETY:` proof.
+
+#![deny(unsafe_op_in_unsafe_fn)]
+#![deny(clippy::undocumented_unsafe_blocks)]
+
+pub mod channel;
+pub mod section;
+pub mod wdf;
+
+/// `NT_SUCCESS` — an NTSTATUS is an error iff negative.
+#[inline]
+#[must_use]
+pub const fn nt_success(status: wdk_sys::NTSTATUS) -> bool {
+    status >= 0
+}