Rename Schunix to SchOS; the kernel becomes SchIFT

Removes the "-unix" element and with it any trademark exposure to The
Open Group.

The split follows the ecosystem layout: SchOS is the system, and the
kernel has its own name. Kernel-identity strings are the only places
that take SchIFT -- uname(2) sysname, /proc/version, and the two licence
sentences that say "kernel" outright. That is what every Unix does here:
`uname -s` on Linux reports the kernel, not the distribution. Everything
a user reads as the product -- panic screen, boot menu, error prefixes,
docs, LICENSE, NOTICE -- is SchOS.

schunix.img is schos.img, the logo assets and the musl TLS patch are
renamed, and __SCHUNIX__ is __SCHOS__ (the define and the patch that
consumes it moved together).

Two things the rename broke, both found by the bootcheck suite:

  - shmtest wrote "SCHUNIX-MMAP-OK" with a hardcoded length of 15 and
    compared it back by hand-counted offsets (m[3]=='U', m[14]=='K').
    The shorter marker left the write running two bytes past the literal
    and the compare reading past the data, failing a file-backed mmap
    that was working correctly. Now written and compared through one
    constant with sizeof.
  - bootcheck asserted a 31-byte file after appending to
    "hello-from-schunix"; the shorter string makes it 29.

Both are the same mistake: a string literal whose length is written out
somewhere else. Full suite green -- base, Tty, Ps, Sock, Fb, Usb, Evdev.

docs/roadmap.md

@@ -7,7 +7,7 @@ plus an installer and a `.sip` package format.
 This file records two things that are easy to lose: the *order* the work has
 to happen in, and the decisions that constrain it.
 
-**Superseded in direction, not in order.** Schunix is now aimed at being a
+**Superseded in direction, not in order.** SchOS is now aimed at being a
 *system* rather than a Unix-like kernel with a userland attached: a NeXTSTEP/
 macOS-shaped layering, with POSIX kept complete but demoted from identity to
 personality, and a native API (**SchAPI**) above it. See
@@ -189,7 +189,7 @@ width text is not a font change, it is a text-rendering layer.
       as-is if wanted; writing one is also reasonable and more interesting
 - [ ] **The typefaces, decided 2026-08-09.** Both verified, not assumed:
       **Roboto** for the desktop, window manager and compositor --
-      **Apache-2.0**, the same licence as Schunix, so it needs nothing beyond a
+      **Apache-2.0**, the same licence as SchOS, so it needs nothing beyond a
       NOTICE entry.
       **JetBrains Mono** for the terminal and TTY -- **SIL OFL 1.1**, and
       notably with *no* Reserved Font Name declared, so it may be modified and
@@ -205,7 +205,7 @@ width text is not a font change, it is a text-rendering layer.
 **Font licensing: public domain or very permissive only.** No SIL OFL if it
 can be avoided, no "free for personal use", no CC-BY-SA. The constraint is
 the same one that governs drivers (§1): a font file is redistributed inside
-every Schunix image, so its licence attaches to the image.
+every SchOS image, so its licence attaches to the image.
 
 Safe choices, in rough order of usefulness:
 
@@ -237,7 +237,7 @@ key-down/key-up with modifiers and no line discipline at all — an evdev-style
 
 ### Phase 6 — Installer and `.sip`
 
-`.sip` (Schunix Installation Package), the stated model being WIM in Windows
+`.sip` (SchOS Installation Package), the stated model being WIM in Windows
 PE: a *file-based* image rather than a block image, so one file can hold a
 whole filesystem, be applied to a partition of any size, and hold several
 images that share their common files.
@@ -301,7 +301,7 @@ sysvinit is not the config format, it is *demand launching*: launchd holds the
 listening socket or watches the path, and starts the job when something actually
 arrives. That inverts the dependency graph — jobs stop needing to declare what
 must start before them, because the thing they depend on answers on first use.
-Schunix already has the two pieces that makes possible: `AF_UNIX` sockets
+SchOS already has the two pieces that makes possible: `AF_UNIX` sockets
 (`kernel/net/unix.c`) and a real `/proc`. What is missing is a supervisor that
 can hold a socket on a job's behalf and hand it over on exec, plus a job
 description format. Prerequisite for this being worth anything: `ps` and `top`
@@ -360,7 +360,7 @@ palette and a layout, none of which care how the pixels were found. What does
 not survive is every assumption in `stage2main.c` about where things live in low
 memory (see `docs/layout.md`).
 
-### SchFS beyond Schunix
+### SchFS beyond SchOS
 
 Three ideas parked 2026-08-08, in the order they should happen.
 
@@ -447,7 +447,7 @@ Three details worth keeping:
 - The ceiling is **3 GB**, because `kvmalloc()` maps 0–4 GB as four 1 GB pages
   and marks the top one uncached for PCI BARs.
 - Below `PHYSTOP_MIN` it prints why and stops, rather than triple faulting in
-  silence. At 24 MB: `e820: only 23 MB usable; Schunix needs at least 24 MB`.
+  silence. At 24 MB: `e820: only 23 MB usable; SchOS needs at least 24 MB`.
 
 The original text is kept below because the reasoning still applies to the SMP
 half of §3b, which is the same shape of bug: a constant nobody revisited.