init survives stray signals; commands are 4-34x faster

Two bugs reported from actual use, plus a test harness that had stopped
testing.

init could be killed by Ctrl-C, taking the machine with it. SIGINT goes
to the foreground process group, init is pgid 1, and any window where
tty_fg_pgrp is 1 -- before a shell claims the terminal, after one exits,
or between the two while the key is held -- lands it on init. init has
no handler, so killed was set, exit() ran, and exit() panics outright on
initproc. Spamming Ctrl-C at a frozen program is exactly the input that
finds that window. POSIX and Linux both discard a default-action signal
for pid 1; init_ignores() now does the same, SIGKILL included, because
init is not killable from userspace on any Unix.

Everything was slow because BSIZE was 1024 while a SchFS block is 4096,
so every block cost four IDE requests, each with its own interrupt and
sleep/wakeup. exec() of the 800 KB toybox binary meant ~800 round trips.
The giveaway: `seq 1 200`, which touches no file and prints nothing,
cost the same 2.0s as `cat /bin/toybox`, and `ls | wc -l` cost exactly
double -- both dominated by loading the same binary twice.

BSIZE is 4096 now, one request per SchFS block, and NBUF is 256 blocks
(1 MB) rather than 90 KB -- smaller than the binary every command execs,
so nothing was ever still resident. ideinit() issues SET MULTIPLE MODE,
which is what makes a 4096-byte transfer legal: READ/WRITE MULTIPLE move
the drive's multiple count per interrupt and nothing had ever set it,
which is the real reason idestart() carried a sector_per_block > 7 panic.

  seq 1 200          2.02s -> 0.06s
  ls /bin            2.76s -> 0.68s
  ls /bin | wc -l    4.68s -> 0.73s

And the harness. bootcheck called Find-Qemu from a param() default,
which is bound before any function in the body exists -- so it died on
its first line and printed an error containing neither "FAIL" nor
"Exception", the two things being grepped for. It had not run since it
was made host-portable. Worse, an earlier index-based edit had deleted
the Expect blocks for -Tty, -Usb, -Sock, -Ps and -Evdev, so five of the
seven modes asserted nothing at all. Restored, and the USB run gets its
own 16 MB build/usbstick.img: it had been pointed at build/fs.img, which
nothing builds since SchFS became root, so QEMU refused to start.

242 checks across seven modes, all passing, and make schfs-check green.

Makefile

@@ -711,6 +711,27 @@ $(BUILD)/sysroot.stamp: sysroot-install
 	@cmp -s $@.new $@ || mv -f $@.new $@
 	@rm -f $@.new
 
+# A small block device for the USB test to read.
+#
+# bootcheck -Usb attaches this as a usb-storage device and has the driver read
+# block 1 off it, which is the only check that separates "a device answered
+# INQUIRY" from "the driver can actually transfer data".
+#
+# Its own image, not the root volume and not build/fs.img:
+#   - attaching the root volume twice (once as hdb, once over USB) broke the
+#     xHCI interrupt check as well as the storage ones;
+#   - build/fs.img is no longer built by anything, since SchFS became the root,
+#     so pointing at it meant QEMU refused to start at all;
+#   - at FSSIZE blocks it would now be ~600 MB, because BSIZE went from 1024 to
+#     4096. 16 MB is plenty to read one block from.
+USBSTICK = $(BUILD)/usbstick.img
+$(USBSTICK): $(MKFS) $(BUILD)/sysroot.stamp
+	@mkdir -p $(BUILD)
+	@rm -f $@
+	$(MKFS) $@ --size 4096 --sysroot $(SYSROOT)
+
+usbstick: $(USBSTICK)
+
 $(BUILD)/fs.img: $(MKFS) $(BUILD)/sysroot.stamp
 	@mkdir -p $(BUILD)
 	@echo "Creating SchOS File System Image..."