build: the libavr pin advances past the audit sweep, and two gates start meaning something

The pin crosses libavr's phase-6 close and the guideline sweep behind it.
All 37 chips green, 43 tests each, the README size table matching every
built image, and all 13602 flash images byte-identical to the previous pin.

The bump broke one gate and exposed another as ornamental.

`check_unit.cmake` matched the autobaud loader's measured unit by the symbol
`unit_E`; libavr's rule-46 sweep renamed the member to `m_unit`, which the
mangling spells `6m_unitE`. On the RAM-home chips the check went red and said
so. On the GPIOR chips it went green - the branch that asserts the unit is
*not* in RAM passes on an empty match, and an empty match is what a stale
regex returns for every image. Both branches mean something again.

`tools/check.sh` ran the 37-chip loop under `set -e`, so the first red chip
ended the gate and the 36 behind it were never built - a stale size canary on
attiny13 would have been an alibi for every loader after it. It accumulates
now and fails at the end naming every red preset, which is the shape libavr's
own check.sh carries and the reason it carries it.

The port's own sweep, verified by byte identity: the four TSB tiers' 16-byte
info block is `std::to_array` rather than an extent written beside the
sixteen elements the compiler can count, the three-member serial and loader
configs break one member per line, the turn-around loops are braced, and the
test fixture's config pair is a deduced `std::array` (rules 36, 40, 34). Two
comments stop narrating how the code came to be and one stops citing a repro
at a path it left two phases ago (rules 12, 13).

pureboot's identity stamp stays the raw array rule 36 bans, and now says why:
its reads must fold to immediates because the bytes are in program memory and
a formed address is dereferenced as data space. As a `std::array` the read
loop stopped unrolling and emitted exactly that - measured at +8 B and a
wrong answer on the wire.

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

tsb/tsb_pure.cpp

@@ -23,7 +23,11 @@ using dev = avr::device<{.clock = 16_MHz}>;
 // 115200 at 16 MHz lands +2.1 % off, past the receiver-tolerance table the
 // solver holds rates to - the oracle's own deployment has run there for a
 // decade, so the override states that it is meant.
-using serial_t = dev::uart0<{.baud = 115200_Bd, .allow_baud_error = true, .half_duplex = true}>;
+using serial_t = dev::uart0<{
+    .baud = 115200_Bd,
+    .allow_baud_error = true,
+    .half_duplex = true,
+}>;
 inline constexpr serial_t serial{};
 
 namespace tsb {