Handle memtest recovery probe under set -e

bible-local/decisions/2026-04-01-memtest-build-strategy.md

@@ -58,6 +58,18 @@ Root cause of the false alarm:
 - as a result, we re-entered the same memtest investigation loop even though
   the real ISO was already correct
 
+Additional correction from the subsequent `v3.21` build logs dated 2026-04-01:
+
+- once ISO reading was fixed, the post-build debug correctly showed the raw ISO
+  still carried live-build's default memtest layout (`live/memtest.bin`,
+  `live/memtest.efi`, `boot/grub/memtest.cfg`, `isolinux/memtest.cfg`)
+- that mismatch is expected to trigger project recovery, because `bee` requires
+  `boot/memtest86+x64.bin` / `boot/memtest86+x64.efi` plus matching menu paths
+- however, `build.sh` exited before recovery because `set -e` treated a direct
+  `iso_memtest_present` return code of `1` as fatal
+- so the next repeated loop was caused by shell control flow, not by proof that
+  the recovery design itself was wrong
+
 ## Known Failed Attempts
 
 These approaches were already tried and should not be repeated blindly:
@@ -102,6 +114,8 @@ Any future memtest fix must explicitly identify:
 - and a post-build proof from a real ISO, not only from intermediate workdir files
 - whether the ISO inspection step itself succeeded, rather than merely whether
   the validator printed a memtest warning
+- whether a non-zero probe is intentionally handled inside an `if` / `case`
+  context rather than accidentally tripping `set -e`
 
 ## Decision
 
@@ -134,6 +148,8 @@ Current implementation direction:
   - install a stable ISO reader in the builder image
   - fail with an explicit reader error if ISO listing/extraction fails
   - do not treat reader failure as evidence that memtest is missing
+  - do not call a probe that may return "needs recovery" as a bare command under
+    `set -e`; wrap it in explicit control flow
 
 ## Consequences