AsahiLocker 1.13.1 — CI on aarch64 only, and a test that cannot hold a runner

A follow-up to 1.13.0. No change to luks-deploy.sh or to any volume it has
made; this is CI scope and documentation.

The x86_64 leg is gone

The loopback matrix ran on ubuntu-latest and ubuntu-24.04-arm. On
2026-09-21 the x86_64 job hung in tests/multi-install-selection-test.sh: it
printed the stage-1 header and then nothing for an hour, until the run was
cancelled. The identical tree passed on aarch64 in 48 seconds.

The cause is not established, and this release does not claim to fix it.
What it does is stop pretending x86_64 is this project's problem. AsahiLocker
is Apple Silicon tooling — the boot guards, the ESP stub handling and the
U-Boot work all assume the m1n1 → U-Boot → GRUB chain — and in-place LUKS2
encryption everywhere else is
LinuxLocker, which covers Fedora,
RHEL, Rocky, AlmaLinux, Debian, Ubuntu, Mint, Pop!_OS, Raspberry Pi OS, Arch,
Manjaro, EndeavourOS and openSUSE, handles systemd-boot and signed UKIs
alongside GRUB, and is tested on its own terms.

The README and docs/FAQ.md now send non-Apple-Silicon readers
there, instead of the old half-claim that the core script "also works on"
Fedora x86_64, Arch and Manjaro. It still does; it is simply not where it is
developed or tested first.

A blocked test fails in five minutes, not an hour

The suite runs under timeout 300 in CI, and stage() marks every
pick_partition call, so if it blocks again the log names the call that was in
flight when the timeout fired.

That guard is deliberately in the workflow and not in the script. An in-script
watchdog was written first and was worse: killing the watchdog subshell leaves
its sleep orphaned, and the orphan holds the inherited stdout open — so
anything reading the suite through a pipe hangs on after the tests have already
finished. It was caught locally, before it shipped.

Upgrading: nothing to do. No behaviour change in any script.