boot: the disc that could not be chainloaded, and the error nobody could see

Reported from a real laptop booting through Ventoy: the F8 menu appears,
selecting Boot SchOS gives a black screen and a white dash in the corner.
Both halves of that are bugs.

The disc could not be chainloaded. Booting it directly, firmware runs the
El Torito FAT image and the loader opens \schos\kernel on that volume,
which is where mkiso.sh put it. Ventoy does not use El Torito at all: it
mounts the ISO 9660 tree and runs \EFI\BOOT\BOOTX64.EFI from there. The
loader then looks for the kernel on the volume it was itself loaded from
-- the ISO tree -- and the kernel was only ever inside the FAT image. It
is now in both. The comment in mkiso.sh had even described this failure,
as the reason the kernel is in the FAT image, without noticing the ISO
tree had the same requirement.

The error was invisible. print() redirects to the serial port once the
splash is up, which is right for a development machine and useless on a
laptop: the loader died with a perfectly good explanation and sent it to
a wire nobody was holding. What is left on screen is the firmware's own
cursor -- the white dash. die() now draws the message on the framebuffer
too, over a cleared band so it does not land on the logo.

Verified by reproducing the exact failure: the ISO tree extracted and
booted as a plain volume, as a chainloader presents it. With the kernel
removed it dies visibly with "no kernel at \schos\kernel or \kernel, EFI
status 0x000E" -- EFI_NOT_FOUND, which is what the laptop was hitting
silently. With it present, that same volume boots through to a shell.

110 [ok] on the ESP path, the ISO check passes, no failures.

tools/posix/mkiso.sh

@@ -89,9 +89,22 @@ if ! command -v mformat >/dev/null 2>&1 || ! command -v mcopy >/dev/null 2>&1; t
 fi
 
 rm -rf "$STAGING"
-mkdir -p "$STAGING/boot" "$STAGING/EFI/BOOT"
+mkdir -p "$STAGING/boot" "$STAGING/EFI/BOOT" "$STAGING/schos"
 
 cp "$EFIAPP" "$STAGING/EFI/BOOT/BOOTX64.EFI"
+# The kernel in the ISO 9660 tree as well as inside the FAT image.
+#
+# Not redundancy for its own sake: it depends on who loaded us. Booting the
+# disc directly, firmware runs the El Torito FAT image and the loader opens
+# \schos\kernel on that volume. But a chainloader -- Ventoy is the common one
+# -- ignores El Torito entirely, mounts the ISO 9660 tree and runs
+# \EFI\BOOT\BOOTX64.EFI from *there*. The loader then looks for the kernel on
+# the volume it was itself loaded from, which is now the ISO tree, and a disc
+# with the kernel only in the FAT image cannot answer.
+#
+# The symptom is precise and was reported from a real machine: the loader comes
+# up, draws its menu, and then dies with EFI_NOT_FOUND.
+cp "$KERNEL" "$STAGING/schos/kernel"
 
 # The FAT image for the UEFI El Torito entry.
 #