A slot the firmware was told to boot is not taken for the committed one

[DevomB]

After any applied update the earlier release stays on the disk, bootable: rollback needs it, its kernel is signed, its root verifies. A firmware entry or BootNext naming \EFI\kryptik\kryptik-<other>.efi, set from firmware setup or from another system, boots it. boot-success looked at the ESP's committed slot only on a degraded state, so on a normal boot it found no trial, recorded ok, and left the entry in place.

What that gave someone who can set firmware variables and nothing else: a silent return to a release whose defects have since been fixed, at every boot if BootOrder was used. The next kryptik-update apply would then take the newer, committed slot as its target, and its refusal of a downgrade compares against the older version that runs.

Found by reading; not reproduced on a machine. That a firmware boots such an entry is how UEFI works, not something this tree shows.

Based on #224, now in main; the branch merges into main b69b728 without conflict.

The change, in build/service-scripts/boot-success.sh:

• With no trial on record, it reads the committed slot off the ESP at every boot (a read-only mount more).
• A slot that runs, is not the committed one, and has no trial on record, on a state that is readable: recorded as uncommitted <slot>, never ok. Its firmware entries are forgotten, the committed slot gets its own, and the machine reboots, once.
• If it comes up there again (an entry that is not Kryptik's own outlives the forgetting), it is left running and still reported: a machine has to stay up to be put right. A boot of the committed slot clears the record of that one reboot.
• The degraded case is as before: another slot than the committed one is a trial whose record cannot be read.
• An ESP that names no committed slot, or something that is not a slot, accuses nobody.

What it does not do: stop someone who rewrites the ESP itself, since the committed slot's name there is not signed. The signed manifest kept for the clock's floor (#181) could give a second opinion from inside the state partition; that is not built here.

kryptik-update is unchanged. A person who booted the earlier slot on purpose from the firmware's menu is sent back once; the ways to return to an earlier release are kryptik-update rollback and kryptik-recover --commit-slot from the medium.

Tests: tools/tests/boot-success.sh gains the cases (reported, entries forgotten, one reboot, no second, none while the entries cannot be removed, cleared by a boot of the committed slot, an ESP naming nothing or nonsense). A plain boot's expected calls now hold the read of the ESP. No suite boots the other slot without a trial; the update suite in the Distro run is the proof that none of its trials, rollbacks or recoveries is taken for one.

Distro run 37350816683 at 4aa080d: every acceptance part green (install, update, production, integrity and zones, inputs, build, boot and desktop). CI green.