Chart VoidKontrol wayfinding and correct current hidraw evidence

KREO-SWARM75-LINUX-CONTROL-SPEC.md

@@ -49,11 +49,20 @@ is `1` — but it is not RGB control.
 
 ### Linux access requirement
 
-This laptop's kernel does not provide `hidraw` (`modprobe hidraw` reports that
-the module is absent).  A native controller therefore requires a kernel with
-`CONFIG_HIDRAW=y` or `CONFIG_HIDRAW=m`, plus a narrow udev rule granting the
-controller service access to the matching hidraw node.  It must select the
-node that represents interface 1 / usage `0xff00:0x01`.
+**Corrected by a read-only recheck on 2026-09-21:** the running kernel
+`7.2.6_1` has `CONFIG_HIDRAW=y`, and both Swarm HID interfaces now have hidraw
+nodes. The earlier `modprobe hidraw` failure did not establish missing
+support: Linux defines `CONFIG_HIDRAW` as a boolean, not a separately loadable
+module option (`CONFIG_HIDRAW=m` is not valid).
+
+A native controller requires `CONFIG_HIDRAW=y` and a narrow udev policy
+granting its device service access to the matching node. At the recheck,
+interface 1 was `/dev/hidraw5`, owned by `root:root` with mode `0600`; the
+desktop user could neither read nor write it. Node numbers are dynamic and
+must not be hard-coded. Select interface 1 / usage `0xff00:0x01` and validate
+the complete descriptor before enabling control. See the dated
+[device evidence](docs/evidence/2026-09-21-swarm75.md) and
+[Linux HID Kconfig](https://github.com/torvalds/linux/blob/master/drivers/hid/Kconfig).
 
 Do **not** use libusb by detaching or unbinding `hid-generic`: that can take
 the keyboard away from the desktop.  A read-only libusb `GET_REPORT` attempt