One missing brace in 27 specs, and three layers of diagnostics that named the wrong subsystem

[gHashTag]

emit-bitexact has been red since 2026-08-14 (#2184). The cause is one character.

A bulk edit appended test <name>_w339_batch_depth_invariant_2 { to 27 spec files and omitted the closing } in every one. The parser then hits the next test keyword while still inside the block:

parse error in fn 'ternary_mac_w339_batch_depth_invariant_2' near line 1815:
unexpected token after expression statement: KwTest

That message is exact — file, function, line, token. Nothing surfaced it, because three layers each reported something else:

layer	said	true?
CI gate	IGLA RACE CROSS-TARGET MISMATCH	no — nothing was compared
verify_igla_race.py	FAIL: C backend failed to build/run	no — the backend never ran
t27c	parse error … near line 1815	yes

verify_igla_race.py runs its builds with capture_output=True and inspects only returncode, so the compiler's message was collected and discarded. A diagnostic that names the wrong subsystem costs more than none: it sends the reader to the backend, and the top-level claim ("the C and Rust backends diverge") is far more alarming than the truth.

After closing 27 braces, verify_igla_race.py exits 0:

OK ternary_mul/mac:      C == reference BIT-EXACT over 800 vectors
OK ternary_mul/mac:      Rust == reference BIT-EXACT over 800 vectors
OK systolic_ternary_pe:  C == reference BIT-EXACT over 800 vectors (i16 psum)
OK systolic_ternary_pe:  Rust == reference BIT-EXACT over 800 vectors (i16 psum)
IGLA RACE ternary MAC + systolic PE BIT-EXACT ACROSS TARGETS (C + Rust + model)

So there was no cross-target divergence. #2184 is corrected by this: the i16 + i8 no-cast gap in gen_rust is real and separately documented in the script, but it is worked around there and was never what made the gate red.

Not in scope, deliberately. Closing the braces reveals that 15 of 27 igla specs still fail on unrelated parser features (unknown cast target type f32, Unexpected top-level token: KwModule), overlapping #2174. Those are a different class and are reported, not fixed here.

Gate: tools/check_specs_parse.py asks the question those three layers did not — does t27c accept the file — and prints the compiler's own message. It carries a negative control that plants an unclosed block and proves the gate rejects it.

Refs #2184