feat(v4): the machine boots from its ROM; the prebuilt nucleus is gone

The host node starts in its ROM (entry 12), and the boot feeds it the
system's source through the console: capsules/v4/sys/map-64.f18, the
fourteen .f18 blobs and end.f18, each found, hash-checked and
signature-checked as any capsule, then EOT.  The ROM assembles the system
and starts it at (IDLE); the host reads the image record
(v4_image_from_node) for what only the assembled system knows.  A ROM
error is reported with its blob, line and meaning, then PARITY:FAIL.

Deleted: v4/tools/mkimage.c, capsules/v4/nucleus-64.f18, v4/capsule/*.v4,
v4/tools/v4tof18.py.  The .f18 files are the source now.

- text.c speaks the rest of the ROM's language (set, here, store, start;
  v4_text_value, v4_text_start), so the oracle reads the same source:
  test_host_rom_nucleus compares the ROM against text.c on the .f18 files,
  word for word, image record included.  Host tests load the .f18 files.
- mkmap image writes v4_map_image (the map's description of the system);
  hosted and the kernel link the ROM and the map instead of v4_image_64.c.
- Hera (Captain Bob's ruling, option 1): births stream the system the ROM
  assembled, as assembled code; hera.4th is unchanged.
  test_host_unit's host builds the system with the ROM.
- New parity lines: PARITY:V4_F18 per blob, PARITY:V4_ROM words=2049
  rom_hash=0xa6c792b5821010b7 instructions=60725216.

Acceptance: amd64, aarch64, riscv64 boot to ok> with PARITY:V4_POST
tests=538 pass=538 fail=0, POST: PASSED, and PARITY:V4_SYSTEM
word_count=317 dict_hash=0xe5a57f3eb72ff94a on all three -- the same hash
as the prebuilt nucleus gave.  make -C v4 test test-32 hosted-check: all
pass.  Logs: logs/20261015-141648, -141938, -142350.

Startup cost under QEMU TCG, the ROM's assembly (last V4_F18 line to
V4_ROM): amd64 26.7 s of 132 s to ok>; aarch64 41.0 s of 195 s; riscv64
20.5 s of 101 s.  Hosted native: +0.85 s.

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

docs/v4.0.0/DATASHEET-F18.md

@@ -96,7 +96,9 @@ registers (§10.3).
 - **I/O addresses** (§10) sit inside the address space. A fetch from or store to one goes to
   the device, not to RAM. The exceptions are NODE-ERROR, which writes RAM and then traps, and
   the console receive addresses, where a store goes to RAM.
-- **ROM.** Designed, not built: `MACHINE.md` §2, and plan Task 1. It is a read-only range at
+- **ROM.** Built (2026-10-15; `MACHINE.md` §2): 2049 words of F18 code, `capsules/v4/rom`,
+  assembled by `v4/tools/mkrom.c`. The machine starts at its entry 12 and assembles the
+  system's source (`capsules/v4/sys`) from the console. It is a read-only range at
   `V4_NODE_WORDS` and above. It can be fetched and executed. A store there is an address fault.
   In the model it is attached by the owner, as every device is, and a reset detaches it.
   - Its routines are shared code, GA144-style (`MACHINE.md` 2.1). Payloads call them through
@@ -307,7 +309,10 @@ These are reported, not hidden:
    and it is not to be extended.
 2. **Device addresses are attached by the owner, not fixed.** D-4 (the memory map) is deferred.
    The FPGA needs fixed addresses.
-3. **The ROM range** is designed (`MACHINE.md`) and not built.
+3. **The ROM** is built and the host node boots from it (2026-10-15). The ROM is the full
+   assembler, about 2000 words, so it is the host node's. A mesh node's small loader ROM
+   (the agreed correction, `JUSTIFICATION.md` §9) is not built yet. Until it is, a node that
+   is born is sent the host's assembled system through its port.
 4. **`stack.h`'s opening comment** still says there is no overflow detection "and there never
    will be". D-16 revised that, and the header carries a revision note above it. The code
    counts and guards (§4). The comment's first paragraph is out of date.