build: the libavr pin advances past phase 6, at byte parity everywhere

The pin crosses libavr's phase 6 - the renamed system surface, the named
serial configs, the receiver-tolerance table, the paged SPM receipts -
and every loader image comes out size-identical: the full matrix on six
representative chips (the exhaustive cross product on three of them),
the stock and autobaud columns untouched, the four tsb tiers back on
their recorded floors at 510/526/638/836.

Byte parity was not free, and the two libavr defects it surfaced were
fixed there rather than absorbed here. The EEPROM write procedure's
step 2 - the SPMEN spin - had landed unconditionally and cost every
build six bytes for a wait a polled loader can never take; it is scoped
now, and the loaders state the datasheet's own omission clause
(spm_interlock::omitted, DS40002061B 8.6.3). The blocking page
erase/write grew an internal wait the tiers' settle() already provides,
so the tiers issue the command form and pureboot keeps its host-driven
sp_spm path.

What the port states rather than inherits: the stock 115200 at 16 MHz
sits +2.1 % past the receiver-tolerance table libavr now holds rates
to, so the hardware links say .allow_baud_error = true - the same
2.5 % envelope pureboot_baud_feasible() has always enforced, proven on
silicon across the fleet. rx_ready() reads readable() now.

Alongside the pin: rule 33's ASCII sweep over every source (docs keep
their typography), rule 34's InsertBraces in .clang-format with the
tree reformatted, std::array over the simavr runners' raw buffers, and
the stale Studio size in ide/README.md replaced by the claim its
check-flags gate actually holds.

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

test/test_handshake.py

@@ -3,15 +3,15 @@
 
 `_handshake` drains the line after it sees a prompt, to absorb a real loader's
 trailing bytes before it asks for the identity. That drain must be bounded: a
-target that never falls quiet — a board stuck in a reset loop presents exactly
+target that never falls quiet - a board stuck in a reset loop presents exactly
 this, ~60 reboots/s of UART-reset garbage in which a stray 0x2b reads as a
-prompt — otherwise spins the tool forever. Regression for that hang, plus a
+prompt - otherwise spins the tool forever. Regression for that hang, plus a
 control that a well-behaved loader still connects.
 
 The handshake must also survive its own leftovers: after `--stay` the loader's
 final prompt can still be in the USB pipeline when the next invocation opens
 the port, and on a board wired to reset on open, that opening starts a fresh
-activation window the stale prompt then betrays — the tool commits to an
+activation window the stale prompt then betrays - the tool commits to an
 identity read against a device that never heard its knock, and what it finally
 collects is the application's banner. StaleDTRPort is that moment as a port.
 
@@ -85,7 +85,7 @@ class StaleDTRPort:
     session's final prompt is still in transit and lands only after the
     opening flush has already run; the reset holds the device off the line
     at first, eating anything written before it completes; and the fresh
-    window is finite — once it expires the application boots and prints a
+    window is finite - once it expires the application boots and prints a
     banner whose bytes are what a pending identity read collects. A
     handshake that trusts the stale prompt spends the whole window waiting
     on a device that never heard its knock; one that drains the line first
@@ -195,7 +195,7 @@ def main():
     check("well-behaved loader still connects (version 5)", info.version == 5)
 
     # the stale prompt: a --stay leftover plus reset-on-open must not burn the
-    # fresh window — the pre-knock drain absorbs it and the first real knock
+    # fresh window - the pre-knock drain absorbs it and the first real knock
     # lands inside the window.
     try:
         stale_ok = pb.Loader(StaleDTRPort()).connect(2.5).version == 5