PRE-REGISTERED, 2026-11-05, written while the single-core campaign was still running on the board
and before any of its numbers had been read, and before the four-core bitstream was ever loaded.

WHY. The single-core prediction put gibbs-recall at ~5 mW, at or below the paired protocol's
floor. The notes' own lesson (FEASIBILITY_parity_2026-10-04.txt): amplify the effect, don't average
the noise. rtl/edge_multi.v puts four engines behind one port; `vqpu-edge meter <class> ... --cores 4`
runs the same job on all four at once (BroadcastPort), so the effect is ~4x while the sensor quantum
and drift stay put.

WHAT IS MEASURED. The same run/halt protocol as the single-core campaign, on the four-core
bitstream, 100 MHz, classes t0-recall and gibbs-recall.

PREDICTIONS
  1. Scaling: P_dyn(4 cores) / P_dyn(1 core, this day's campaign) = 4.0, PASS range 3.4 .. 4.6 for
     t0-recall. Outside it, cores do not add independently (shared clock tree, placement density,
     rail), and the per-core numbers from the four-core build must not be divided by four.
  2. t0-recall, four cores: 4 x 122 = 488 mW (range 240 .. 1000), i.e. four times the single-core
     prediction, whatever the single-core measurement turns out to be.
  3. gibbs-recall, four cores: 4 x 5 = 20 mW (range 0 .. 80). If the single-core run could not
     resolve it, this is the number that can: at 20 mW and SE ~6 mW it is ~3 sigma.

LABEL. Board-level, this KV260, this (four-core) design. Per-core figures from it are the four-core
value divided by four only if prediction 1 passes.