driverkit: fast stuck-key recovery after VHID daemon reconnect (MAL-57 Layer 2)

[malpern]

Summary

When the socket to the Karabiner VHID daemon dies mid-keystroke (CPU starvation under parallel builds, daemon restart), a key Release lost in transit leaves the DriverKit virtual keyboard holding that key down. The daemon only garbage-collects the dead client after its own heartbeat timeout, so the key autorepeats at the OS level for 1-3 seconds. Two live incidents on 2026-06-10 were traced end to end — see KeyPath docs/bugs/MAL-57-duplicate-keypresses.md (2026-06-10 Incident Evidence) and KeyPath PR malpern/KeyPath#882 (Layer 1, launchd priority fix).

Changes

Vendors karabiner-driverkit 0.3.1 into driverkit/ via [patch.crates-io] with three targeted changes:

1. Stable per-PID client socket path (virtual_hid_device_service/client.hpp). The daemon keys per-client state — including the DriverKit virtual keyboard instance — by this path. A reconnect under the same path reuses the existing keyboard instead of spawning a second instance while the stuck one repeats until GC. local_datagram::client_impl already removes an existing file before bind, so stale files are harmless.
2. virtual_hid_keyboard_reset on the keyboard-ready rising edge (c_src/driverkit.cpp). Clears any stuck key as soon as the connection recovers. Safe for held keys: kanata's next posted report carries absolute full state (the C++ report object tracks all pressed keys), so genuinely-held keys are re-asserted by the next event.
3. Client server-check interval 3000ms → 1000ms. Detects a dead daemon connection ~2s sooner; the daemon already pings each client at 1000ms, so no new traffic class.

Also: virtual_hid_keyboard_ready is now printed only on transitions instead of every ~1s daemon status push — this was 95%+ of the 183MB daemon stdout log.

Worst-case stuck-key window drops from ~3s to ~1.5s; typical under 1s. No Rust-side changes; cargo build and cargo check pass with the patched crate resolving from driverkit/.

Test plan

• cargo check / cargo build green with the vendored patch
• Manual verification planned via KeyPath integration: SIGSTOP the VHID daemon for >3s while holding a key, resume, confirm the stuck-key burst is bounded by ~1s and held modifiers survive benign reconnects
• Log verification: virtual_hid_keyboard_reset sent after ready transition appears on reconnect; ready-spam gone