boot: the BIOS loader is gone

1449 lines of boot/bios/, tools/sign.pl and tools/padstage2.pl, plus the
build rules, the disk image and the ISO entry that existed to carry them.

Everything since roughly 2012 boots UEFI, and CSM -- the firmware-side
BIOS emulation that lets a legacy loader run on such a machine at all --
has been going away since Intel dropped support for it in 2020. So this
is not a path being retired early; it is one whose remaining hardware is
already the exception.

The cost was never the code, it was the tax on everything near it. Stage
2 had a 65-sector ceiling it overflowed silently -- 25440 bytes against
24576 -- and because the kernel is written at sector 1 + STAGE2_SECTORS,
an overflowing loader was overwritten by the very kernel it was loading.
The resolution list could not be shared with UEFI either: VBE mode
setting is INT 10h, so matching it needed unreal mode, which is the
riskiest code in the tree for a feature that already worked elsewhere.

What replaces schos.img is the staged ESP, handed to QEMU as a virtual
FAT volume. That is a development arrangement and not an installable
disk; a real GPT image with a real FAT partition is the installer's job,
and until it exists nothing here writes a disk a machine boots unaided.
Secure Boot is untouched too -- the loader is unsigned.

The ISO keeps one El Torito entry, the FAT image holding loader and
kernel. It never booted from a USB stick via BIOS anyway: the firmware
presents the stick as a hard disk while stage2main.c read the kernel back
over ATAPI.

The 32-bit multiboot entry in entry.S now has no caller and is left in
place. Deleting kernel entry code is its own change with its own way of
failing silently, and it should not ride along with this one.

Ported with it: run.ps1, the six screenshot tools, and schcom_test.sh,
each with its own OVMF varstore copy so no run inherits another's UEFI
variables.

Two things this shook out. OVMF now belongs in `all`: nothing boots
without firmware, `make clean` wipes build/ including the copy fetched
from the host, and a clean followed by a build left every run script
throwing. And it cannot be listed as a prerequisite at the top of the
file -- make expands prerequisites when it reads the line, and
$(OVMF_CODE) is defined further down, so naming it there appends nothing
and says nothing.

Verified from a clean tree: 110 [ok] and no failures on the full suite,
the ISO boots with no hard disk attached, schfs-check passes, schcom's
end-to-end pixel test passes, and fbshot captures a real 1280x800 frame.

docs/layout.md

@@ -52,7 +52,7 @@ schos/
 
 ```
 build/
-├─ boot/          bootblock, stage2
+├─ boot/          uefi/ loader, common/ UI
 ├─ kernel/        object files, the linked kernel, kernel.asm
 ├─ lib/           libc glue objects, initcode blob
 ├─ cmd/           linked first-party programs
@@ -114,8 +114,9 @@ compiled objects first. Switching back is the same — plain `make` after a
 `ramroot` build reuses stale objects, so run `rm -rf build/kernel build/lib
 build/cmd` first (or just `make clean`).
 
-The image costs boot time: stage2 loads the kernel by PIO one sector at a time,
-so a 6 MB ramroot kernel is visibly slower to start than the 350 KB default.
+The image costs boot time: the loader reads the kernel through the firmware's
+file protocol, so a 6 MB ramroot kernel is visibly slower to start than the
+350 KB default.
 
 **What may go in it is a licensing question, not only a size one.** The image is
 linked into the kernel binary, so anything in `sysroot/` when it is built becomes
@@ -154,22 +155,16 @@ Makefile has `--redefine-sym` lines mapping e.g.
 blob's build location and those symbol names change; update the Makefile to
 match or the kernel fails to link.
 
-**`STAGE2_SECTORS` now lives in exactly one place: the root `Makefile`.** It used
-to be written out by hand in five — `boot/bios/bootasm.S`, `boot/bios/stage2main.c`'s
-`readseg()`, the `dd ... seek=` offset, and twice more inside `tools/posix/mkiso.sh`
-(its stage2 size assertion and `-boot-load-size`). This note used to warn you to
-keep three of them in step and did not know about the other two.
+**`STAGE2_SECTORS` is gone, with the BIOS loader it sized.** It is recorded here
+because the shape of the bug outlived it: one number that four files each
+believed independently — `boot/bios/bootasm.S`, `stage2main.c`'s `readseg()`,
+the `dd ... seek=` offset, and twice inside `mkiso.sh`. Raising it from 24 to 48
+for the boot logo left the `dd seek=25` offset behind, so the kernel was written
+directly over stage 2's own tail, and nothing said so.
 
-Raising it from 24 to 48 for the boot logo demonstrated the problem: the `dd
-seek=25` offset stayed behind, so the kernel was written directly over stage2's
-own tail. Now the Makefile passes `-DSTAGE2_SECTORS` to both boot sources,
-derives the padding budget and the `seek=` offset from the same variable, and
-exports it to `mkiso.sh`. The `#define`s that remain in the two boot sources are
-`#ifndef`-guarded fallbacks so those files still read sensibly alone; the
-Makefile always wins.
-
-Two things still fail the build rather than silently misbooting, and should stay
-that way: `tools/padstage2.pl` errors if stage2 overflows its budget instead of
-truncating it, and `boot/bios/stage2main.c` static-asserts that stage2 cannot reach
-the multiboot kernel-search buffer at `0x10000` — which puts the hard ceiling at
-65 sectors, since stage2 loads at `0x7E00`.
+The fix was to derive all five from one Makefile variable. The lesson worth
+keeping is the other half: `tools/padstage2.pl` *failed the build* when stage 2
+overflowed its budget rather than truncating it, which is why the overflow to
+25440 bytes against a 24576 limit was found at all. A layout constant that
+several artifacts must agree on wants a check that stops the build, not a
+comment asking people to remember.