tools: group scripts by what runs them

tools/windows/   .ps1   (pwsh, so usable from Linux and macOS too)
  tools/posix/     .sh
  tools/python/    .py
  tools/           .c and .pl

The .c and .pl files stay at the top level because they are not
host-specific: the build compiles or invokes them on every platform.

Call sites updated in the Makefile, ports/mk/port.mk, docs and the
project memory. The one thing that does not survive a move on its own is
a script deriving the repo root from its own location -- all nine
PowerShell tools used Split-Path $PSScriptRoot -Parent, and memory-sync.sh
used dirname/.., both of which quietly become tools/ one level deeper.
Two levels now.

Two pre-existing Windows failures surfaced while verifying, both real and
neither caused by the move:

  - schfs_fsck.c did not compile under mingw at all: --extract uses
    POSIX mkdir(path,mode), symlink() and link(), none of which mingw
    has. That took the whole tool with it, and `make schfs-check` with
    it. mkdir maps to _mkdir; symlink and link fail loudly rather than
    writing a regular file in their place, because an extracted tree
    that differs from the image while reporting success defeats the
    point of --extract.
  - the round-trip test then failed at `ln -s`, since Git Bash cannot
    create symlinks without developer mode. It skips with a message now.
    Not a fudge: mkschfs's mingw build cannot see a symlink either, so
    the test would have compared a tree with none against an image with
    none and called it a pass -- coverage reporting itself as present
    while being absent.

Verified on Windows: build clean, all seven bootcheck suites green,
make schfs-check passes.

docs/architecture/kernel-history.md

@@ -483,7 +483,7 @@ the user is looking at. That single fact is most of what separates a hobby
 project from a product; every shipping system puts that behind a flag.
 
 `cons_serial_only` already existed for panic, so the fix was to start it *set*.
-Everything still goes out the UART — which is where `tools/bootcheck.ps1` reads
+Everything still goes out the UART — which is where `tools/windows/bootcheck.ps1` reads
 it from, so all five suites kept passing untouched — and `console_takeover()`
 clears it on the first `exec()`, the moment userspace genuinely starts.
 `vga_init` no longer clears the screen, so the splash survives the whole of

docs/architecture/schfs.md

@@ -324,9 +324,9 @@ tools/mkschfs.c              build an image from a directory tree
 tools/schfs_fsck.c           verify, list, extract
 tools/schfs_test.c           B-tree torture harness
 tools/schfs_objtest.c        object layer: files, directories, space accounting
-tools/schfs_roundtrip.sh     end-to-end filesystem test
-tools/mutate.sh              mutation-tests the suites themselves
-tools/bootcheck.ps1          boots under QEMU and drives the shell
+tools/posix/schfs_roundtrip.sh     end-to-end filesystem test
+tools/posix/mutate.sh              mutation-tests the suites themselves
+tools/windows/bootcheck.ps1          boots under QEMU and drives the shell
 ```
 
 Everything except `kmount.c` is compiled *both* into the kernel and into the
@@ -357,7 +357,7 @@ is the least glamorous: after deleting everything, free space must be back to
 exactly what it was on an empty volume. Every other test in the suite still
 passes on a filesystem that leaks a block on every delete.
 
-`tools/mutate.sh` injects six deliberate bugs and fails if any of them goes
+`tools/posix/mutate.sh` injects six deliberate bugs and fails if any of them goes
 undetected. It is how the suites are kept honest; see the note in §9.
 
 ### Verifying on real hardware

docs/building.md

@@ -46,9 +46,9 @@ make USE_GNU=1 TOOLPREFIX=x86_64-elf-
 ## Testing
 
 ```sh
-tools/bootcheck.ps1               # boots, drives the shell, asserts on output
-tools/bootcheck.ps1 -Tty -Ps      # plus terminal behaviour and process listing
-make schfs-check                  # SchFS unit, object and image suites
+tools/windows/bootcheck.ps1            # boots, drives the shell, asserts on output
+tools/windows/bootcheck.ps1 -Tty -Ps   # plus terminal behaviour and process listing
+make schfs-check                       # SchFS unit, object and image suites
 ```
 
 `bootcheck` is PowerShell, and PowerShell 7 (`pwsh`) runs on Linux, macOS and
@@ -67,6 +67,27 @@ not work on a Windows host** — `make` prints `ports: skipped` and uses whateve
 is already staged in `sysroot/`. Building them needs a Linux host (or any other
 Unix); do it once and the staged result serves the Windows builds.
 
+## Where the tools live
+
+`tools/` is grouped by what runs the file, so it is obvious at a glance which
+tools a given host can use:
+
+```
+tools/
+  windows/   .ps1   PowerShell (pwsh runs these on Linux and macOS too)
+  posix/     .sh    shell
+  python/    .py
+  *.c               host programs -- compiled by the build, run everywhere
+  *.pl              perl, likewise
+```
+
+The `.c` and `.pl` files stay at the top level because they are not
+host-specific: the build compiles or invokes them on every platform.
+
+A script that needs the repo root derives it from its own location, so anything
+moved between these directories has to have that adjusted — the PowerShell tools
+use `Split-Path (Split-Path $PSScriptRoot -Parent) -Parent`, two levels up.
+
 ## Known host differences, already handled
 
 Listed because they are the shape of the next such bug, not because anything is
@@ -75,7 +96,7 @@ outstanding:
 - `<sys/sysmacros.h>` is glibc/musl only. macOS and the BSDs take `major()` and
   `minor()` from `<sys/types.h>`.
 - `sha256sum` exists on Linux and Git Bash; macOS has `shasum -a 256`,
-  FreeBSD/NetBSD `sha256`, OpenBSD `cksum -a sha256`. `tools/sha256check.sh`
+  FreeBSD/NetBSD `sha256`, OpenBSD `cksum -a sha256`. `tools/posix/sha256check.sh`
   finds whichever is present.
 - `nproc` is coreutils, so absent on macOS and BSD, where it is
   `sysctl -n hw.ncpu`.
@@ -88,7 +109,7 @@ outstanding:
 Claude Code's project memory is kept in the repo and moved with:
 
 ```sh
-tools/memory-sync.sh status
-tools/memory-sync.sh export   # after a session that learned something; then commit
-tools/memory-sync.sh import   # after cloning or pulling elsewhere
+tools/posix/memory-sync.sh status
+tools/posix/memory-sync.sh export   # after a session that learned something; then commit
+tools/posix/memory-sync.sh import   # after cloning or pulling elsewhere
 ```

docs/layout.md

@@ -26,7 +26,7 @@ schos/
 │                 suites, sign.pl, vectors.pl, and the PowerShell harnesses.
 │                 Their binaries build into build/tools/ -- this directory
 │                 used to hold both, which is the one rule this layout has.
-│                 tools/loc.ps1 counts how much of the tree is first-party.
+│                 tools/windows/loc.ps1 counts how much of the tree is first-party.
 ├─ sysroot/       Staging for the disk image. etc/ is hand-maintained;
 │                 bin/ lib/ sbin/ are populated by `make sysroot-install`.
 ├─ dist/          Upstream tarball cache. Survives `make clean`.
@@ -156,7 +156,7 @@ 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/bootasm.S`, `boot/stage2main.c`'s
-`readseg()`, the `dd ... seek=` offset, and twice more inside `tools/mkiso.sh`
+`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.
 

docs/roadmap.md

@@ -281,13 +281,13 @@ into `sysroot/`, which is linked into the kernel binary for a ramdisk-root
 build. That combination is a licensing accident waiting to happen, for a test
 that was passing every time.
 
-**What replaced it:** `tools/bootcheck.ps1` with its `-Sock`, `-Evdev` and `-Ps`
-modes, plus `tools/splashshot.ps1` for the boot path. These are narrower and do
+**What replaced it:** `tools/windows/bootcheck.ps1` with its `-Sock`, `-Evdev` and `-Ps`
+modes, plus `tools/windows/splashshot.ps1` for the boot path. These are narrower and do
 not prove the whole stack composes, which is the honest cost of the removal.
 
 **The lesson worth keeping** is the shape of the test, not the program: the next
 full-stack test should be something large that we did not write, driven to a
-real pixel-level assertion rather than a log line. `tools/splashshot.ps1`'s
+real pixel-level assertion rather than a log line. `tools/windows/splashshot.ps1`'s
 colour counting exists because a log-only harness once passed on a blank screen.
 
 ### Phase 8 — The system layer: `schinit`, firmware, and a crash channel