M3-family support: SoC detection, software rendering, M3 installer path, branch kernels

[frybagivxx-gif]

Summary

Makes Omarchy Mac installable and usable on M3, M3 Pro and M3 Max Macs on the public Asahi trees as they are today, and shaped so the day Asahi ships the M3 display driver and GPU driver nothing here needs a migration.

Where Asahi is (September 2026): the kernel Asahi Alarm ships (7.1.6) has device trees for every M3 machine, m1n1 1.6.1 boots them, the installer lists them in expert mode against firmware 14.8.3. What is in no public tree: the M3 display driver wiring (a 14.7 DCP ABI exists in asahi-wip-7.2 and chadmed's dcp/14.8.3, but no branch attaches it to the M3 device trees) and any M3 GPU (G15) support in the kernel driver or Mesa. Asahi says an official M3 release is weeks away; the GPU is later.

• bin/omarchy-hw-apple-soc — generation from the device tree (m1..m4), codename, and --gpu: whether the Asahi GPU driver is actually bound. Everything keys off that rather than a model list. (Related: Detect Apple Silicon generations from device tree #326, which does identity only; this is deliberately minimal and adds the GPU question.)
• Software rendering when there is no GPU driver — vulkan.sh installs vulkan-asahi only when the driver is bound; default/hypr/apple.lua (loaded from envs.lua next to nvidia.lua) sets AQ_NO_MODIFIERS, software cursors, no direct scanout and vfr, checked at every session start so a kernel that binds the driver turns them off by itself. install/hardware/apple/m3.sh says on the console what the machine will not do.
• bin/omarchy-mac-asahi-install — runs on macOS (bash 3.2). The stock Asahi Alarm installer refuses M3 only because installer_data.json lists no image built against firmware 14.8.3; the Asahi developers' instruction for M3 testing is to add it by hand (Add M3, M3 Pro and M3 Max devices using macOS 14.8.3 OTA AsahiLinux/asahi-installer#424, Adds ENV var to get bat using the system theme omarchy#438). This fetches the same installer and images from asahi-alarm.org, adds "14.8.3" to every supported_fw, briefs the user, and hands over. On M1/M2 it runs the stock data unchanged.
• pkgbuilds/linux-asahi-wip + bin/omarchy-mac-kernel-wip — build any branch of any Asahi fork with Asahi Alarm's kernel config and install it alongside linux-asahi (GRUB lists both). The branch is a build-time choice, so the M3 display branch is a one-line change when it is public.
• Docs — docs/apple-m3.md, README step 1 M3 variant, manual note, and an M3 warning in omarchy-mac-setup before "Start?".

Test plan

• test/shell.d/apple-soc-test.sh — 15 cases against stubbed device trees and sysfs (M1/M2/M3/M3 Max/M4, codename, --is, non-Apple, simpledrm-only vs asahi-bound vs platform-bus binding)
• test/shell.d/apple-m3-test.sh — leaf wiring, vulkan gating, envs.lua, PKGBUILD parses and does not conflict, installer wrapper parses under bash 3.2, patch_installer_data against multi-line / one-line / already-present / empty / null lists, idempotent, target-name mapping
• tests/test-asahi-compatibility.sh passes; tests/test-mac-setup.sh unchanged (132 pass / 10 fail on a macOS host, identical to quattro)
• patch_installer_data run against the live https://asahi-alarm.org/installer_data.json: adds 14.8.3 to the five image entries, leaves tethered boot's null alone
• Real install on a MacBook Pro 16 M3 Pro (J516s) — this is what I have and will report back on; not done before opening this so the approach can be reviewed first

🤖 Generated with Claude Code

[frybagivxx-gif]

Opened from the wrong account by mistake; resubmitting from staccDOTsol.