009: Magisk ship pack through US-S5-1 + US-S4 OpenSSH/Jelly/Gallery2.

Release-keys/AVB, CVE clean+hi batches, Yama/slabrand, Pro branding,
bundled apps, and AXP-class product surface docs/scripts.

docs/009-fortify-v4-clean-tests-verification-20260927.md

@@ -0,0 +1,50 @@
+# Verification of clean C and X experiments — 2026-09-27
+
+Independently parsed the binary dumps and recorded kernel/boot properties in:
+
+- `.local-artifacts/009-v4-clean-c-20260927T190738Z/`
+- `.local-artifacts/009-v4-x-persist-20260927T191143Z/`
+
+The clean C test removes the earlier X/latch confounder: T2 has a zero failure
+zone and a fresh v4 #29 boot; T3 reports kernel_panic on an intermediate v4 boot;
+T4 is combo4 #16. No complete failure record is present after C. The intermediate
+boot prevents localization of loss to the panic itself versus later boot stages.
+
+The X test demonstrates that all eight complete 55-byte X records survive the
+normal recovery to combo4 unchanged. It does not include the panic transition
+of the C test, so it is a recovery control rather than the same full sequence.
+
+Precision correction: T3 and T4 are NOT identical binary dumps. Their first 128
+bytes match, but 7,213 bytes differ across 4 MiB, including six bytes in the first
+1 KiB. Likewise X2 and X3 have 79 differing bytes, despite their complete X
+records surviving intact. These differences do not negate X persistence, but
+avoid describing entire zones or dumps as identical. Their cause is not yet
+established.
+
+Next diagnostic should check a full C record (primary and mirrors, expected
+event/id/caller/terminator) immediately after its writer and before panic.
+The success/failure result must be observable independently of the storage
+whose survival is under test. A print to a console that cannot be retrieved, or
+another flag only in the same alt region, would repeat the observability problem.
+A control-only two-phase arm/readback/trigger protocol can expose the record
+and status through adb before deliberately entering panic; document the changed
+timing and validate the actual immediate path subsequently. Keep normal FORTIFY
+failure behavior intact.
+
+This establishes a narrower investigation: the writer plus normal recovery can
+work; a clean panic experiment still loses or fails to produce the record.
+Selective AES overwrite and a safe alternative offset remain unproven.
+
+## Follow-up: two-phase arm/readback/panic (same evening)
+
+Artifact:
+`.local-artifacts/009-v4-twophase-x-then-c-20260927T191809Z/`
+
+Using existing v4 (no rebuild): SysRq-x → **adb dump confirms** eight
+complete `AXPDIAG1,X` records → SysRq-c (latch no-ops C write; panic runs)
+→ intermediate v4 (`kernel_panic`) → combo4.
+
+Result: pre-verified X is **absent at P3 and P4**. Independent channel was
+adb, not alt-only flags. Timing caveat: adb RTT between arm and panic; type
+X not C. Narrow reading: fail-zone content verified before panic does not
+survive this panic/reboot path; soft recover without panic still preserves X.