Apply package-owned device tree overlays to m1n1 stage 2

[joshuaswarren]

A package can now add a device tree node that the kernel's device trees do not have yet, and omarchy update keeps working.

Why

The ANE driver (joshuaswarren/omarchy-ane) binds only to an apple,t*-ane node. linux-aurora 7.1.12 and linux-asahi 7.1.13 do not ship one. Today a Mac cannot add it: the boot check refuses a changed package DTB, a DTBS entry the kernel package does not own, and a boot.bin that differs from its rebuild. So update-verify stops omarchy update.

After omacom#13362, this plugs straight into its update-verify operation: omarchy-mac-boot is the package that implements it, and this branch touches only omarchy-mac-boot.

What changes

• A package ships a compiled overlay as /usr/share/omarchy-platform/dtb-overlays/PREFIX/NAME.dtbo, the platform root the rest of quattro-upstream and Converge omarchy-mac and omarchy-mx-mac into upstream Omarchy omarchy#13362 use. PREFIX selects device trees by file name: t8103 selects every t8103-*.dtb.
• Any package may ship one: a new SoC or a new device needs only a new .dtbo in that package's file list, never a change to omarchy-mac-boot. Once this merges, omarchy-ane moves its overlays into this directory and drops its own update-m1n1 hooks.
• /etc/default/update-m1n1 sources lib/dtb-overlays.sh. When an overlay applies to one of the newest kernel's device trees, DTBS names that kernel's device trees, with overlaid copies in /run/omarchy-dtb-overlays in place of the originals. The kernel's files do not change, so the mtree check still holds.
• With no overlays, DTBS keeps update-m1n1's default and boot.bin is byte-identical to today.
• An overlay with the root property omarchy,skip-if-compatible stays out of a device tree that already has that node. When a kernel adds the node, the kernel's node is used.
• An overlay with the root string omarchy,opt-in applies only when that string is a line of /etc/omarchy-platform/dtb-overlays.opt-in. This is for hardware whose driver must not start until the owner chooses it. The first user is the M2 Max ANE, whose driver cannot be unloaded once it starts. The boot check reads the same file.
• If an overlay fails to apply, or dtc cannot read the result, that device tree stays as the kernel shipped it.
• dtc older than 1.7.1 gets no overlays. Its fdtoverlay gives a labelled existing node a new phandle, and every reference to the old phandle then points nowhere. Measured: with dtc 1.6.1 the T8103 AIC went from 0xf to 0xc7. libfdt 1fad0650 and 61e88fdc (both in v1.7.1) fix this.
• The boot check applies the same overlays when it rebuilds boot.bin. Each overlay must belong to a package. The check reads /etc/default/update-m1n1 with OMARCHY_DTB_OVERLAYS=0, so reading it builds nothing.
• 95-omarchy-mac-dtb-overlays.hook runs update-m1n1 when a package adds, changes or removes an overlay. This is the same step 95-m1n1-install.hook runs after a kernel update. Please review this hook with extra care.

DKMS update-verify breakage

omarchy-apple-silicon-boot-check also runs the kernel package's mtree against the installed files. The kernel ships modules.dep and the sibling maps and depmod rewrites them on every install and after any DKMS module, so their modification time, size and SHA-256 checksum never match the mtree once a DKMS package (ANE, xone, xpadneo, …) is present. Until now the check only tolerated modification-time mismatches there, so a fresh omarchy update on a Mac with any DKMS module failed with "installed linux-aurora files do not match the package mtree: warning: linux-aurora: /usr/lib/modules/7.1.12-2-7-ARCH/modules.alias (Size mismatch)". A size or checksum mismatch on a modules.* file is now accepted only while depmod -o $fresh $kver over the installed modules reproduces the file byte for byte; modules.builtin and modules.builtin.modinfo are depmod's inputs, not its outputs, and stay strict. A map that depmod would not write, or one it writes differently (a corrupted or stale map), still fails.

Tests

• New test/dtb-overlays-test.sh, with real dtc: prefix selection, skip-if-compatible, opt-in, a failed overlay, same bytes on every run, the update-m1n1 DTBS result, and dtc before 1.7.1.
• test/apple-silicon-boot-check-test.sh: an overlaid boot.bin passes in --boot-chain and full mode. A stale boot.bin fails. An overlay that no package owns fails. The depmap acceptance runs depmod against the fixture's modules tree.
• The whole boot package suite ran in an x86_64 Arch chroot with CI's package list plus dtc: 25 of 28 files pass on this branch, 24 of 28 on the base branch (fd9b7e88). The same three files fail in both runs (mac-migrate-test.sh, mac-migrate-mx-test.sh, mac-reset-test.sh) — pre-existing failures unrelated to this branch.
• After the opt-in commit, the files that read the library (dtb-overlays, apple-silicon-boot-check, update-m1n1-locale, update-verify, mac-boot-install) pass again in the same chroot.
• In an aarch64 Arch Linux ARM chroot, the real asahi-scripts update-m1n1 (20260127.1-1) wrote boot.bin to a file, not an ESP. The overlaid T8103 and T6001 device trees were in it, and the check's rebuild path produced the same bytes. With no overlays, boot.bin equaled m1n1 + the stock DTBs + U-Boot.

Tested on a MacBook Pro 13-inch M1 (T8103) running a fresh Omarchy install: the ANE overlay from a package applied to boot.bin on update-m1n1, the board device tree carried the node after reboot, and the driver bound (/dev/accel/accel0).

For the package recipe

omarchy-mac-boot needs dtc in checkdepends for the new test. At run time, dtc is needed only when overlays exist. The package that ships an overlay depends on it. CI now installs dtc.