v3.1.2 Release pipeline patch

Same shipped software as v3.1.1 (the Debian security floors and the HP
Pavilion fixes), re-tagged so the release is produced end to end by CI:
the v3.1.1 tag run built and gated the ISO and imported the signing key,
then died staging the signed assets because the runner had no xorriso or
unsquashfs. Tags are immutable, so v3.1.1 stays a source tag with a
CI-built but unpublished ISO; v3.1.2 is the first release whose split,
signed assets and draft GitHub Release come from the tag run alone
(release-process §10 remains the fallback). Also carries the User Guide
version slots the v3.1.1 prep missed and the QEMU boot-flake diagnostics
(#141).

Fixed

• Release pipeline: signed staging on the runner. The v3.1.1 tag build
  passed every gate and imported the signing key, then died at "xorriso is
  required to verify a signed ISO": stage-split-release.sh verifies the
  ISO's inventory, dpkg database and boot kernel with xorriso and unsquashfs on
  the runner, and ubuntu-latest ships neither. release.yml now installs
  xorriso and squashfs-tools before staging, and check_workflows.py
  asserts the step exists and precedes staging. v3.1.1 itself was finished the
  manual way (release-process §10) from the run's artifact.
• User Guide release slots. The v3.1.1 release prep bumped manifest.json,
  the README and the Dockerfile but not the two <!--orionx:release--> slots
  in docs/User_Guide.md, so test_operator_surfaces.sh failed on develop and
  main at the tag ("release slots say v3.1.0, want v3.1.1"). Both slots now say
  v3.1.1; the footer states which ISO passed which checks.
• QEMU boot flake made diagnosable (#141, DEC-PHASE13-028). The QEMU Boot
  Test has failed intermittently since 2026-10-25, in one firmware mode per run
  (UEFI six times, BIOS once) while the other mode passes: the first-boot
  wizard's plymouth quit never satisfies plymouth-quit-wait, the 25 s cap
  fires, serial-getty@ttyS0 starts and no login prompt ever prints, and from
  then on nothing user space writes to the console tty appears while kernel
  messages keep arriving. Local QEMU and the HP Pavilion boot. Three changes,
  none of which alters a healthy boot: the wizard's plymouth quit is bounded
  (timeout 10) so a wedged splash cannot stall onboarding;
  plymouth-quit-wait.service gains OnFailure= →
  orionx-plymouth-diag.service, which records plymouth, getty, DRM, serial
  driver and console termios state plus every holder of the console through
  /dev/kmsg (prefix ORIONX-PLYMOUTH-DIAG), the kernel path that provably
  reaches the serial log when the tty path does not; and qemu-boot-test.sh
  prints that block plus every systemd failure line when a mode fails,
  instead of only the last 50 lines. The root cause is still open in #141;
  the next failure will carry its own evidence.

Download and verify

GitHub caps release assets at 2 GiB per file, so the 3151036416-byte ISO is
published as 16 parts (part-aa … part-ap). Download ALL 16 parts,
SHA256SUMS and SHA256SUMS.asc into one directory.

1. Reassemble (Linux / macOS):

   cat orionx-phoenix-edition-v3.1.2.iso.part-* > orionx-phoenix-edition-v3.1.2.iso

   Windows (cmd, or PowerShell via cmd /c):

   copy /b orionx-phoenix-edition-v3.1.2.iso.part-aa + orionx-phoenix-edition-v3.1.2.iso.part-ab + orionx-phoenix-edition-v3.1.2.iso.part-ac + orionx-phoenix-edition-v3.1.2.iso.part-ad + orionx-phoenix-edition-v3.1.2.iso.part-ae + orionx-phoenix-edition-v3.1.2.iso.part-af + orionx-phoenix-edition-v3.1.2.iso.part-ag + orionx-phoenix-edition-v3.1.2.iso.part-ah + orionx-phoenix-edition-v3.1.2.iso.part-ai + orionx-phoenix-edition-v3.1.2.iso.part-aj + orionx-phoenix-edition-v3.1.2.iso.part-ak + orionx-phoenix-edition-v3.1.2.iso.part-al + orionx-phoenix-edition-v3.1.2.iso.part-am + orionx-phoenix-edition-v3.1.2.iso.part-an + orionx-phoenix-edition-v3.1.2.iso.part-ao + orionx-phoenix-edition-v3.1.2.iso.part-ap orionx-phoenix-edition-v3.1.2.iso

2. Verify. The reassembled ISO MUST hash to:

   2718be02e596ddd5a5750252af5accc22865552b583dc0a0bd3a79c170b14d5c

   Linux:   sha256sum -c SHA256SUMS
   macOS:   shasum -a 256 -c SHA256SUMS
   Windows: Get-FileHash orionx-phoenix-edition-v3.1.2.iso -Algorithm SHA256

   SHA256SUMS also lists each part, so a bad download can be pinpointed and
   re-fetched without pulling everything again.

   Then check the signature on the checksums (signing key
   4CB08BD1D0B3281613DD15DB1DCCDF47FEEDEEEF — compare it with the fingerprint published outside this repository):

   gpg --recv-keys 4CB08BD1D0B3281613DD15DB1DCCDF47FEEDEEEF     # or import it from a trusted copy
   gpg --verify SHA256SUMS.asc SHA256SUMS

3. Write to USB (8 GB or larger; the ISO is hybrid: UEFI and legacy BIOS):

   Linux:   sudo dd if=orionx-phoenix-edition-v3.1.2.iso of=/dev/sdX bs=4M status=progress conv=fsync
   macOS:   sudo dd if=orionx-phoenix-edition-v3.1.2.iso of=/dev/rdiskN bs=1m

Do not flash a single .part-* file. It is not bootable on its own.