docs(bastion): state the rescue-SSH evidence at its actual strength

The previous wording claimed the failure was "reproduced on x86_64", which
overstates it. The aarch64 observation is direct -- port 22 probed for 30
minutes with the Anaconda environment demonstrably up. The x86_64 run only
shows SSH not becoming available inside a 15-minute budget; that VM was
never observed reaching the rescue environment, because vitest's reporter
discards the streamed log.

The distinction decides where the next person looks, so it should not rest
on an inference presented as an observation.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015nRFZXpKwUVE4SRSHw6GjF

bastion/docs/ARCHITECTURE.md

@@ -485,12 +485,20 @@ Hardcoded `/dev/sda` default broke NVMe-only machines. Fix: default to empty str
 integration coverage for `provision debug` (`tests/integration/pxe-rescue.test.ts`) showed the
 rescue environment coming up correctly — the bastion serves the kernel and initrd, Anaconda
 boots, fetches `debug.ks`, and reaches its installer environment — but **nothing ever listens on
-port 22**. Confirmed on aarch64 by probing the port for 30 minutes while the Anaconda environment
-was demonstrably running (NetworkManager, polkitd, rsyslog all up), and reproduced on x86_64 with
-KVM, so it is not architecture-specific and not an emulation artefact.
+port 22**.
 
-This is orthogonal to the multi-architecture work: the same failure occurs on x86_64, which that
-work does not touch. Leads worth checking, in order:
+Strength of the evidence, stated precisely because it decides where to look next:
+- **aarch64 — direct.** Port 22 probed every 20s for 30 minutes while the Anaconda installer
+  environment was demonstrably running (NetworkManager, polkitd, rsyslog on the console). Never
+  opened.
+- **x86_64 — corroborating, not conclusive.** One clean KVM run (943s) where SSH never became
+  available inside a 15-minute budget. That VM's progress into the rescue environment was *not*
+  observed — vitest's final reporter discards the streamed log — so it is consistent with the
+  aarch64 result but does not independently prove it. Re-run with `KEEP_VM=1` and probe port 22
+  directly to settle it.
+
+If the x86_64 result holds up, this is orthogonal to the multi-architecture work, since x86_64 is
+untouched by it. Leads worth checking, in order:
 - Does `inst.sshd` actually start `sshd` in `inst.rescue` mode, or only in install mode? The
   port never opens, so this is the prime suspect — an auth problem would still show an open port.
 - `sshkey` may apply only to the *installed* system, leaving the installer environment