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/architecture/schfs.md

@@ -42,7 +42,7 @@ end to end.
 ## 2. What is deliberately not taken
 
 - **No ZFS storage pools / RAID-Z / vdevs.** Multi-disk redundancy is a large
-  subsystem that solves a problem Schunix does not have yet.
+  subsystem that solves a problem SchOS does not have yet.
 - **No btrfs-style rebalancing or online format conversion.** Enormous
   complexity, and it is the historical source of btrfs's worst bugs.
 - **No actual SQL.** No parser, no query planner, no relational engine. See §6 —
@@ -242,7 +242,7 @@ Phases 1-3 are roughly 3,000-4,000 lines and are the bulk of the work. Phase 1
 alone (B-tree + torture harness) is worth doing carefully and unhurriedly; every
 later phase compounds on it.
 
-This is the largest single piece of work in Schunix. It is also entirely
+This is the largest single piece of work in SchOS. It is also entirely
 ordinary filesystem engineering with excellent published references
 (Giampaolo for BeFS; the btrfs design papers; the ZFS uberblock/checksum-in-
 parent scheme) — there is no research risk here, only volume.
@@ -254,7 +254,7 @@ populate this format. Building it against v1 means building it twice.
 
 Three different things get called "the limit", and they are worth keeping apart:
 what the **on-disk format** can express, what **this implementation** can
-currently mount, and what the **rest of Schunix** can carry. The smallest one is
+currently mount, and what the **rest of SchOS** can carry. The smallest one is
 what you actually hit.
 
 ### The format
@@ -292,7 +292,7 @@ raising `SCHFS_SPACE_PAGES` to 4096 makes it 512 GiB at 64 KiB of pointers per
 mount. It is set where it is because the page-pointer vector lives inside
 `struct schfs_vol`, which the kernel holds as static storage.
 
-### The rest of Schunix
+### The rest of SchOS
 
 These are VFS and driver limits rather than SchFS ones: