feat(v4.0.0): POST passes and is part of the boot; U* and U/MOD

The boot is now nucleus, forth79.4th, POST, prompt, on both products.

- forth79.4th: U* and U/MOD, the capsule's first colon definitions.  They
  are in the FORTH-79 Required Word Set and neither v3 nor v4 had them.
- post79.4th: 550 cases, 126 of the 130 required words.  443 are v3's with
  v3's result.  The rest follow three rulings (2026-10-05): address-
  dependent cases are checked for count, not value; where v3 departs from
  FORTH-79 the standard's result is expected; words v3 has no case for get
  cases written by hand.  v4/tools/post79_rules.py holds each exception
  with its reason and docs/v4.0.0/POST79.md lists them all.
- every case starts from an empty stack, DECIMAL and FORTH DEFINITIONS
- the boot requires POST's tally line with fail=0

Verified: tests=550 pass=550 fail=0 and identical PARITY lines on hosted
amd64, aarch64 and riscv64 (make -C v4 hosted-check) and on bare metal,
clean qemu with STARFORTH_V4=1, on the same three (logs/20261005-1619xx,
-1621xx, -1625xx).  A U/MOD broken on purpose fails five cases and stops
the boot.  make -C v4 test passes.

Not shown: all words but those two are still assembled, so POST has so far
tested the assembled words.  Nothing was typed at a bare-metal prompt.
Open: PAD 42 OVER ! faults on v4 (D-1).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/v4.0.0/NUCLEUS.md

@@ -178,10 +178,32 @@ and names each failing case.
 
 ### 6.4 Generating the expected values
 
-A script reads the v3 test modules, keeps the cases for Required Word Set
-words, pipes each line through the hosted v3 binary, and writes the
-`T{ ... }T` lines. It is a development tool, run when the cases change; its
-output, `post79.4th`, is committed and reviewed like any source.
+`v4/tools/mkpost.py` reads the v3 test modules, keeps the cases for
+Required Word Set words, runs them in one session of the hosted v3 binary,
+and writes `capsules/v4/post79.4th`. It is a development tool
+(`make -C v4 post79`), run when the cases or the rules change; its output
+is committed and reviewed like any source. Every case starts from the same
+state on both machines: empty stack, `DECIMAL`, `FORTH DEFINITIONS`.
+
+### 6.5 Where POST does not take v3's word (ruled 2026-10-05)
+
+`v4/tools/post79_rules.py` holds the exceptions, each with its reason, and
+`mkpost.py` writes them out as `POST79.md`, which lists every one.
+
+1. **Address-dependent cases.** A case that leaves or prints a memory
+   address is checked for the number of values it leaves, and for what it
+   prints unless an address is printed. The values are not compared.
+2. **Where v3 departs from FORTH-79.** The expected result is the
+   standard's. Where v3's line is not valid FORTH-79 (`>R` at the prompt, a
+   single number given to `<#`), the line is rewritten so that it is.
+3. **Cases written for v3's machine.** A v4 address unit is a cell (D-1);
+   cases that assume v3's byte addresses are rewritten in v4's terms.
+4. **Words v3 has no case for** get cases written by hand, with the
+   standard's results. `U*` and `U/MOD`, which neither v3 nor the v4
+   nucleus had, are colon definitions in `forth79.4th`.
+
+Not tested: `KEY`, `EXPECT` and `QUERY`, which wait for the keyboard, and
+`QUIT`, which returns to the terminal without ` ok`.
 
 ## 7. Hashing, signing and parity