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.

Makefile

@@ -366,7 +366,7 @@ iso:
 	$(MAKE) RAMROOT=1 schos.iso
 
 schos.iso: $(BUILD)/boot/cdboot $(BUILD)/boot/stage2 $(BUILD)/kernel/kernel
-	STAGE2_SECTORS=$(STAGE2_SECTORS) sh tools/mkiso.sh $@
+	STAGE2_SECTORS=$(STAGE2_SECTORS) sh tools/posix/mkiso.sh $@
 
 # Boot the ISO the way a machine booting off a disc would: no hard disk at
 # all, so a kernel that still secretly depends on one fails here rather than
@@ -644,7 +644,7 @@ schfs-fsck: $(SCHFS_FSCK)
 # the *filesystem* matches a tree that exists independently of it, so a writer
 # and reader that agree on something wrong are still caught.
 schfs-image-test: $(MKSCHFS) $(SCHFS_FSCK)
-	@sh tools/schfs_roundtrip.sh $(MKSCHFS) $(SCHFS_FSCK)
+	@sh tools/posix/schfs_roundtrip.sh $(MKSCHFS) $(SCHFS_FSCK)
 
 # Every SchFS suite. Run this after touching anything under kernel/fs/schfs.
 schfs-check: schfs-test schfs-objtest schfs-image-test
@@ -655,7 +655,7 @@ schfs-check: schfs-test schfs-objtest schfs-image-test
 # the system, which is exactly why it rots. This makes "does it still render"
 # a question with a thirty-second answer. Needs a ramroot build first.
 crashshot:
-	pwsh -File tools/crashshot.ps1
+	pwsh -File tools/windows/crashshot.ps1
 
 # Read the QR code back off a captured crash screen. End-to-end on purpose: it
 # reads the pixels that were painted, so payload construction in panic context,
@@ -663,7 +663,7 @@ crashshot:
 # text comes back. Run `make crashshot` first. Needs the same Python packages
 # as `qrcheck`.
 crashqr:
-	$(PYTHON) tools/crashqr.py
+	$(PYTHON) tools/python/crashqr.py
 
 $(MKFS): tools/mkfs.c include/fs.h include/stat.h include/param.h
 	@mkdir -p $(BUILD)/tools
@@ -773,7 +773,7 @@ LOGO_SRC = Assets/SchOS Small Logo.png
 LOGO_PX  = 128
 
 logo:
-	$(PYTHON) tools/mklogo.py "$(LOGO_SRC)" include/logo.h $(LOGO_PX)
+	$(PYTHON) tools/python/mklogo.py "$(LOGO_SRC)" include/logo.h $(LOGO_PX)
 
 # The USB vendor/product name database, from linux-usb.org.
 #
@@ -826,7 +826,7 @@ qrtest: $(QRTEST)
 #   pip install --target build/pylibs opencv-python-headless numpy segno
 #   PYTHONPATH=build/pylibs make qrcheck
 qrcheck: $(QRTEST)
-	$(PYTHON) tools/qrcheck.py
+	$(PYTHON) tools/python/qrcheck.py
 
 .PHONY: all kernel ramroot cmd ports sysroot-install qemu \
         schfs-test schfs-objtest schfs-image-test schfs-check mkschfs \