feat(v4.0.0): nodes that talk -- ports, a node born empty, and the fabric

MESH.md step 1, in the engine, which knows nothing of StarForth or of any
kernel.

- node: V4_PORTS ports (8), a build parameter; "any port" and the port the
  last such read came from; a read blocks until the neighbour writes, as a
  write blocks until the neighbour reads; v4_node_born: empty, P at "any
  port"
- exec: a fetch from a port -- @ @b @+ @p, or of an instruction word when P
  is a port -- waits for a word; a node executes what arrives at a port
  without advancing P; a blocked node goes on from the slot it stopped at
- fabric: the nodes there are and the table of how their ports are wired,
  both changed while the nodes run; devices on a port; asleep and awake; a
  step is every unblocked node executing one instruction word, then every
  write with a reader waiting being handed over
- DECOMPOSITION.md section 6: four named ports withdrawn for V4_PORTS
  numbered ones and wiring as data, as ruled

Verified: tests/test_fabric.c, 53 checks at both widths: two nodes exchange
words; an empty node is filled through its port by a device, and by another
node, and runs what it was sent; a word is passed on by a node in between;
a waiting node executes nothing; the wiring is changed while they run; a
node is put to sleep, woken and removed while looping; a node is born while
others run; the fabric is given more room.  make -C v4 test and make -C v4
sanitize pass.  The single-node products are unchanged: hosted-check on
three ISAs, and clean qemu with STARFORTH_V4=1 on amd64, aarch64 and
riscv64 with lines typed at each prompt (logs/20261006-074907, -075150,
-075532).

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

v4/README.md

@@ -59,7 +59,7 @@ State, 2026-10-05, after `ENGINE.md` step 1: all six builds start the nucleus,
 load `v4:forth79.4th`, pass POST and reach `ok>`, with the same lines:
 
 ```
-PARITY:V4_NUCLEUS words=298 image_hash=0x2e02147b54f9ff47
+PARITY:V4_NUCLEUS words=298 image_hash=0xd982cf093aadb8b9
 PARITY:V4_CAPSULE name=v4:forth79.4th capsule_id=... dict_hash=...
 PARITY:V4_POST tests=550 pass=550 fail=0
 PARITY:V4_CAPSULE name=v4:post79.4th capsule_id=... dict_hash=...
@@ -68,8 +68,8 @@ POST: PASSED
 ok>
 ```
 
-Bare-metal logs: `logs/20261005-193045/amd64/`, `logs/20261005-193307/aarch64/`,
-`logs/20261005-193636/riscv64/`. On each, seven lines were then typed at the
+Bare-metal logs: `logs/20261006-074907/amd64/`, `logs/20261006-075150/aarch64/`,
+`logs/20261006-075532/riscv64/`. On each, seven lines were then typed at the
 prompt through the serial port — a definition, its use with the capsule's
 `U*`, `COLD`, the capsule word again, a `FORGET` of it (refused), a kernel
 word no one serves, and `BYE` — and each was answered as the hosted binary
@@ -101,6 +101,16 @@ product is its own and may become a hosted SDK. The bare-metal product is
 to be LithosAnanke with the node in the StarForth VM's place, and
 everything about word records, the fleet and identity is its alone.
 
+**Nodes that talk** (`docs/v4.0.0/MESH.md`) are the next step, ahead of
+making v4 equal v3 on bare metal. Its first part is built and tested in
+the engine: a node has `V4_PORTS` ports; a read from one blocks until the
+neighbour writes and a write until the neighbour reads; a node is born
+empty with `P` at its ports and executes what a neighbour sends it; and
+the fabric (`v4/src/fabric.c`) is the nodes there are and the table of how
+their ports are wired, both of which change while they run. The products
+below are still one node each; they become the five nodes at `MESH.md`
+steps 8 and 9.
+
 **This is still the lone node.** On bare metal `kernel_main.c` starts it
 before the fleet tables, beside the kernel's own system and not in the VM's
 place. `ENGINE.md` sets out the steps from here; step 1 is done and step 2 is