Say what the tests need, and count the tools correctly

Two nitpicks from review, and one of them was only half right, which is why
each was checked rather than swept.

THE TEST DEPENDENCIES were nowhere. The README said what building needs and
stopped, so somebody with a C compiler and nothing else would get through
'make' and fall over on 'make test'. It needs bash and Python 3 - two of the
checking scripts are Python, and one of those opens a pseudo-terminal - plus
stty, timeout and the usual text utilities.

"BOTH TOOLS" WAS WRONG IN TWO PLACES OUT OF SIX. 'make sanitize' builds the
default target, which is all three, so the README and the makefile both
undercounted what they rebuild.

The other four are right and were left alone. assembly.h says both tools
have to agree where the vector table begins, and bootstrap.c and cpu.c say
they share the boot image format and the vector layout - in all three cases
that is the emulator and the assembler, and SplitDisk has no opinion about
any of it. The makefile's POSIX comment is the same story: SplitDisk uses
not one POSIX interface, so it names the two that do rather than counting to
three.

Media/ is a home for the screenshot that is coming, with a note saying what
belongs in it and that docs.sh will catch a link to something removed from
it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW

Media/README.md

@@ -0,0 +1,8 @@
+# Media
+
+Screenshots and anything else that is looked at rather than read or built.
+
+Nothing here is used by the build or the tests. The repository's README links to what is
+in here, and `Tests/docs.sh` checks that every one of those links lands, so a file removed
+from here without the link going too will fail the suite rather than becoming a broken
+image on the front page.

README.md

@@ -55,6 +55,8 @@ make
 
 The sources are ISO C and build clean under `-std=c11 -pedantic` with `-Wall -Wextra`. Beyond ISO C they need POSIX.1-2008, which the makefile asks for by name, and `getopt_long` for the long form of the command line options.
 
+Building needs nothing else. **Running the tests needs `bash` and Python 3**, because two of the checking scripts are Python and one of them opens a pseudo-terminal to ask questions a recorded file cannot answer. They also use `stty`, `timeout`, and the usual text utilities: `sed`, `awk`, `grep`, `cmp`, `diff`, `tr`, `sort`, `wc`.
+
 Assemble something and run it:
 
 ```
@@ -174,7 +176,7 @@ because a recorded file cannot answer its question:
 
 A cycle count is deliberately **not** part of a recorded result. The last line of the emulator's output has the number taken out before anything is compared, keeping only whether the program stopped on its own or ran into its limit, which is behaviour. Two instructions added to CosmOS used to move that number in six unrelated files at once, so a real difference would have arrived in a crowd of meaningless ones. Anything that wants to measure cycles should say so in a test of its own.
 
-To rebuild both tools with the address and undefined behaviour sanitizers and run the suite under them:
+To rebuild all three tools with the address and undefined behaviour sanitizers and run the suite under them:
 
 ```
 make sanitize

makefile

@@ -11,7 +11,8 @@ PREFIX ?= /usr/local
 # editing a header rebuilds everything that includes it.
 DEPFLAGS = -MMD -MP
 
-# Both tools use POSIX interfaces that ISO C does not have: realpath, clock_gettime,
+# The emulator and the assembler use POSIX interfaces that ISO C does not have:
+# realpath, clock_gettime,
 # strdup, dirname and getopt. Asking for POSIX.1-2008 by name means the build does
 # not rely on the compiler happening to default to a mode where those are visible,
 # and it survives someone overriding CFLAGS, which is why it is kept separate.
@@ -104,7 +105,7 @@ test: $(EMU_TARGET) $(ASM_TARGET) $(DSK_TARGET) strict
 	@echo
 	@./Tests/docs.sh
 
-# Rebuild both tools with the address and undefined behaviour sanitizers and run
+# Rebuild all three tools with the address and undefined behaviour sanitizers and run
 # the test suite under them. Slower than 'make test', and worth running before a
 # release or after anything that touches memory handling.
 #