tools: measure the ENE read-back question instead of inferring it

P2 asked whether the ENE at 0x27 has readable state. The answer had been
reached twice by elimination, and the last link in that chain was a comment
in a third party's patched OpenRGB detector, not a measurement of ours.

probe-ene-receive-byte.sh runs the experiment the driver made possible on
2026-07-27, when PNTR_SEL (BIT(18)) gave us a bare Receive Byte: a read with
no command byte on the wire cannot return a transform of a register that was
never sent. It does, however, return the last command byte the chip received
— 12/12 on both channels — so the value is still ours, not the device's. A
Receive Byte taken from 0x31 after addressing 0x27 answers 0xff instead of
the echo, which places the latch in the device and not in the iMC engine;
empty addresses NACK, so the transaction is real.

Everything here is read-only: Receive Byte and Read Byte Data at 0x27, SPD
reads through ee1004 sysfs, and the four SPD serials compared before and
after every run.

Two engine behaviours the script has to work around, both measured:
the first transaction on a channel answers with a stale value (hence the
discarded warm-up read), and a read following a successful one usually
NACKs, which one retry always clears — the P1 policy, confirmed.

lore-thread-check.py is unrelated to the probe but shares the same motive:
lore and patchwork now sit behind an Anubis bot check, so a shell cannot
tell "not published" from "not allowed to look". The NNTP mirror can.

tools/README.md

@@ -13,6 +13,19 @@ raw numbers. Do not paraphrase them.
 | `dump-pcu-config.sh` | Which PCU registers move on their own? Is there a TSOD polling control? | no |
 | `probe-cf8-write.sh` | Is the CF8/CFC write really dropped, and does it raise an SMI? | **yes**, requires `--i-understand` |
 
+Not part of the submission: `pre-poweroff-load.sh` — fixed, mixed SMBus load
+to run before every poweroff of the A5 hang observation window (TODO.md E1),
+identical in the `use_ecam=1` phase and the `use_ecam=0` counter-proof.
+3-minute blocks: software effect stream (~2760 writes/s) → rapid hw/sw switch
+burst → hardware effect → full SPD dump via ee1004 + serial integrity check.
+Fully automatic: saves run context + any driver warnings to a per-run file in
+`tools/pre-poweroff-runs/`, appends one summary line to
+`pre-poweroff-load.log`, then — **only with `--poweroff`** — powers the
+machine off (15 s grace, Ctrl-C aborts); without the flag it just reports and
+exits. Run: `sudo ./tools/pre-poweroff-load.sh [minutes] [--poweroff]`
+(default 30; re-execs under sudo by itself). The one exception: an SPD serial
+mismatch saves everything and does NOT power off — investigate first.
+
 ## 1. `watch-engine.sh` — foreign activity (read-only)
 
 Samples the six per-channel registers and reports every change that this
@@ -133,3 +146,50 @@ shown the encoding works.
 A channel found on page 1 is not a fault of this driver: `ee1004`, and
 OpenRGB's `DDR4DirectAccessor::set_page()`, both select a page and leave it
 selected.
+
+## 8. `lore-thread-check.py` — "la patch è stata pubblicata? qualcuno ha risposto?"
+
+Niente hardware: interroga l'archivio **NNTP** di lore, `nntp.lore.kernel.org:119`,
+e dice (a) se un message-id è nell'archivio della lista, con gli header veri, e
+(b) quali articoli successivi appartengono allo stesso thread. Sola lettura, il
+server rifiuta il posting comunque.
+
+```bash
+./tools/lore-thread-check.py [email protected]
+./tools/lore-thread-check.py <msgid> --group org.kernel.vger.linux-kernel
+```
+
+Esce `0` se il messaggio è archiviato, `1` se non c'è, `2` su errore.
+
+> ⚠️ Esiste perché dal browser o con `curl` la risposta è ingannevole:
+> `lore.kernel.org` e `patchwork.kernel.org` stanno dietro il bot-check **Anubis**
+> e restituiscono 403 o la pagina *"Making sure you're not a bot!"* al posto del
+> messaggio — che si legge facilmente come "la patch non è mai stata pubblicata".
+> Il mirror NNTP non ha il challenge. Per patchwork non esiste equivalente: lì
+> serve un browser vero.
+
+## 9. `probe-ene-receive-byte.sh` — la Receive Byte a 0x27 (read-only)
+
+L'esperimento di `TODO.md` §P2, e le sue varianti diagnostiche. Nessuna
+scrittura, su nessun indirizzo: solo Receive Byte e Read Byte Data verso `0x27`
+e letture SPD dai nodi sysfs di `ee1004`. Le quattro seriali SPD sono
+confrontate prima e dopo a ogni run e una differenza è errore fatale.
+
+```bash
+sudo systemctl stop furyd            # lo script rifiuta di partire con furyd attivo
+sudo ./tools/probe-ene-receive-byte.sh --rounds 12   # l'esperimento
+sudo ./tools/probe-ene-receive-byte.sh --latch-test  # eco del command byte + cross-address
+sudo ./tools/probe-ene-receive-byte.sh --map         # ri-deriva l'artefatto N>>2
+sudo ./tools/probe-ene-receive-byte.sh --addr-sweep  # stessa read su altri indirizzi
+sudo systemctl start furyd
+```
+
+Esito del 2026-08-10 (log in `docs/evidence/2026-08-10-ene-*.log`): la Receive
+Byte restituisce l'**eco dell'ultimo command byte** mandato a quel chip (12/12,
+due canali), il latch è del device e non dell'engine (da `0x31` torna `0xff`),
+gli indirizzi vuoti NACKano. **L'ENE non ha stato leggibile** — ora misurato.
+
+> ⚠️ Due trappole, valgono per qualunque misura su questo engine: la **prima**
+> transazione di un canale restituisce un valore stale (per questo lo script fa
+> un read di warm-up scartato), e la lettura successiva a una riuscita NACKa
+> spesso — un solo retry la pulisce sempre, come dice P1.