Match only whole disks in the kyber udev rule

udev patterns are shell globs, so nvme[0-9]*n[0-9]* also matched every
partition. Partitions have no queue/scheduler, and udev logged a "Could not
chase sysfs attribute" for each one at boot. Restrict the match to
SUBSYSTEM block with DEVTYPE disk, which also keeps mmcblk boot areas and
NVMe multipath nodes out.

Reword the comment: kyber targets a read latency rather than bounding it,
and the kernel's default choice depends on the device rather than being a
fixed NVMe versus everything-else split.

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

etc/udev/rules.d/60-omarchy-io-scheduler.rules

@@ -1,6 +1,8 @@
-# Kyber targets read latency (2ms) and throttles writes to hold it, so the
-# desktop stays responsive under a large build, copy, or package upgrade.
-# The kernel default is none for NVMe and mq-deadline for everything else,
-# neither of which bounds latency once the device queue fills. Applies to real
-# disks only; zram is memory and has nothing to schedule.
-ACTION=="add|change", KERNEL=="nvme[0-9]*n[0-9]*|sd[a-z]*|mmcblk[0-9]*|vd[a-z]*", ATTR{queue/scheduler}="kyber"
+# Kyber keeps reads in their own queue and throttles the depth it submits to
+# hold a 2ms read latency target, so interactive reads keep flowing while a
+# large build, copy, or package upgrade floods the disk with writes. The
+# kernel's own pick (none or mq-deadline, depending on the device) does not
+# regulate latency once the queue fills. Whole disks only: partitions have no
+# scheduler of their own, and zram is memory with nothing to schedule. Zoned
+# btrfs disks are moved back to mq-deadline by 64-btrfs-zoned.rules.
+ACTION=="add|change", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", KERNEL=="nvme*|sd*|mmcblk*|vd*", ATTR{queue/scheduler}="kyber"