test(bitnet): assert the DMA address advance per state arm, not by literal count

[gHashTag]

Closes #2384

The defect

dma_local_addr_autoincrement_both_paths counts one literal across the whole emitted
module and requires two:

let bumps = stdout.matches("local_addr      <= local_addr + 12'd1;").count();
assert!(bumps >= 2, "expected local_addr++ on both read and write beats, got {}", bumps);

#2345 (Closes #2003) replaced the read path's post-increment with
local_addr <= beat_index — deliberately, because the post-increment landed beat 0's
data at address 1 and never wrote slot 0. bumps fell to 1 and the test has been red on
master since. #2345's file list is bootstrap/src/bitnet_dma.rs plus its NOW entry; the
test was not touched.

The emitter is correct. The test was stale.

Why it was invisible, and why that is the interesting part

cargo test -p t27c --tests stops after the first failing target, and this is the 42nd of
73 — so it never ran. That is #2382, and this is its first concrete instance: a genuine
regression sitting on master for a day, not because a gate was missing but because the gate
everyone assumed was running had never reached the target. The ratchet landed in #2383 is
what will surface the next one.

Why not lower the threshold

The property the test names — each transfer path advances the destination address — is
still true. Both paths do it, by different mechanisms:

READ_DATA:  local_addr <= beat_index;         beat_index <= beat_index + 12'd1;
WRITE_DATA: local_addr <= local_addr + 12'd1;

On the write path local_addr is a read pointer into local memory, so a post-increment
is right there and must not be harmonised with the read path.

Changing >= 2 to >= 1 would go green and re-open the same blind spot: a global count
cannot say which path a match came from, which is exactly what would let one path silently
lose its advance while the assertion still saw the other. Now sliced per state arm, so
an assertion cannot be satisfied by an identical line in a different state.

Evidence

Three mutants, one per assertion. Each verified planted (planted=1) before running —
an earlier attempt's sed silently matched nothing and the tests passed, which would have
read as "the guard does not bite" had the plant not been checked.

mutant	result
bitnet_dma.rs:217 removed	READ_DATA must present the beat index as the address, not post-increment (that was #2003 — beat 0 landed at address 1 and slot 0 was never written).
:218 removed	READ_DATA must advance beat_index, or every beat writes address 0.
:235 removed	WRITE_DATA must advance local_addr, or every beat reads the same word.

21 passed; 1 failed each time, each caught by its own assertion. Restored:
22 passed; 0 failed.

Baseline pruned 383 → 382, since the test now passes and a fixed entry left in the baseline
is the rot the ratchet's recovery reporting exists to prevent.

What this does not establish

• No emitted RTL changes. This corrects a test that measured surface form instead of the
  property it names.
• This is 1 of the 12 unexamined failures in cargo test -p t27c runs 1 of 73 targets: the 13 known failures hide 60 clean targets and 12 unexamined ones #2382. Eleven remain, and their ages are
  still unestablished — born-failing and just-regressed need different responses.
• Corpus ratchet, coverage and exhaustive-full are red on master already; none is
  required and none is reachable from a test-plus-docs diff.

[github-actions]

📓 NotebookLM Notebook linked to this PR

• Notebook ID: b83263109fb055dc
• URL: https://notebooklm.google.com/notebook/b83263109fb055dc

This notebook contains session context, decisions, and artifacts for this work.

[github-actions]

PR Dashboard

Generated at: 2026-08-22 07:49:29 UTC

• test(bitnet): assert the DMA address advance per state arm, not by literal count #2385 test(bitnet): assert the DMA address advance per state arm, not by literal count | Created: 2026-08-22 | Updated: 2026-08-22 | 16 failing / 26 total
• corpus: freeze the damage, patch one class at a time, and say where one rule stops #2161 corpus: freeze the damage, patch one class at a time, and say where one rule stops | Created: 2026-08-14 | Updated: 2026-08-21 | 0 failing / 9 total
• Unbreak FPGA CI and correct two unbacked hardware claims #2081 Unbreak FPGA CI and correct two unbacked hardware claims | Created: 2026-08-11 | Updated: 2026-08-20 | 5 failing / 27 total

Summary

Status	Count
Total Open PRs	3
PRs with Failing Checks	1
PRs with All Checks Green	2
READY	1
FAILING	1
PENDING	0

Seal Status

• ⚠️ STALE -- sha256(compiler.rs)=fba627661c36 != manifest seal=87e5cbd3ad94.
  The committed NMSE numbers were certified against an older compiler.rs.
  Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).