Make USB control DSP-authoritative and attest firmware builds

[xmutantson]

Why

The USB serial side had never been seriously exercised by scripted control. Based on correspondence with the Winlink team, this is the first systematic scripted use of that interface.

That exposed three correctness failures in released behavior:

• serial profile commands changed S:N and redrew the panel but did not select the DSP profile;
• a convincing panel redraw could therefore show a mode that had never been applied;
• acknowledgments were emitted before the DSP transition completed.

This is test equipment. If the commanded channel and the live channel can differ, every downstream measurement can be mislabeled. The interface must report what the DSP is actually running, not what the parser or display intended.

This consolidated change supersedes PRs #2, #3, and #4. It incorporates their useful work, corrects the ancillary-command regression in #4, and adds the missing trust and build-attestation pieces.

Changes

Tier 0 — make scripted profile selection work

• Apply WGN, MPG, MPM, MPP, and MPD to the live channel mode.
• Restrict live profile replacement to selectors 0–4.
• Let FADE DEPTH, FADE FREQ, OFFSET, input/output gains, and BANDWIDTH update their parameters without replacing the live profile.
• Preserve boot-to-WGN behavior and do not persist channel mode to EEPROM.

The established nine-command profile-first program now ends with live MPP and mode-3 tap initialization:

MPP:25
FADE DEPTH:0
FADE FREQ:0
OFFSET:0
CH1 IN:1
CH2 IN:1
CH1 OUT:1
CH2 OUT:1
BANDWIDTH:3000

Tier 1 — make state authoritative

• Route panel and serial profile changes through synchronous ApplyChannelMode().
• Complete tap/routing initialization before returning OK or the structured ACK.
• Add an applied-generation counter to ACK and STATUS output.
• Make the SIM-to-BUSY command reachable and apply BUSY state before acknowledgment.
• Reject fractional syntax for integer-valued commands before mutation, eliminating contradictory OK/ERROR replies.
• Make STATUS report the live DSP-driving mode, S:N, multipaths, fade depth/rate, offset, four gain settings, bandwidth, measured input/output levels, applied generation, and build identity.
• Keep LEVEL as the STATUS level subset and HELP as the complete command reference.
• Print the same build identity on the physical boot screen, serial boot banner, and STATUS.

Tier 2 — retain maintenance behavior

• Restore RESET with transmit flush before reset.
• Restore CODECINIT, completing codec reinitialization before its response.

Tier 3 — display and repository cleanup

• Retain PR Draw the mode header once when initializing a non-WGN mode #3's duplicate-header predicate correction.
• Remove tracked Python bytecode and ignore generated test caches.
• Clarify HELP output for queries, replies, and maintenance verbs.

Validation` section with

Validation

• Thirteen source-level regression tests pass against both the production and Proto
  sketches where applicable (eight prior tests plus five new source-filter tests):
  the fade internal call is silent (blnOperatorSource=false), both live-loop steady
  calls request the printing source, the print guard is (blnOperatorSource || blnDebugAdjustSN) && (intDesiredSN_dB != intLastDesiredSN_dB), the firehose flag
  defaults off, and the DEBUG verb and STATUS DEBUG= field remain reachable.
• The production sketch is now HFSim_BFD_2_05; its TFT display, serial boot banner,
  HELP banner, and STATUS revision field report Rev 2.05. The Proto sketch follows the
  same revision convention.
• Teensy 4.0 builds use Arduino CLI 1.5.1, Teensy core 1.62.0, teensy-compile 15.2.1,
  and explicit teensy:avr:teensy40:usb=serial,speed=600,opt=o2std,keys=en-us settings.
  Two fresh builds with the same recorded identity produced byte-identical Intel HEX.

Build identity: 7037038@20260921T061316Z

HEX SHA-256: 8567d5e2a91e24b358d0dfd674f310f8a2a26f5199bf0792db7f80919cb4961b

Hardware validation: this exact Rev 2.05 HEX was flashed to the Teensy 4.0 HF
simulator and re-verified over serial and on the audio wire.

• Fail-before / pass-after: on the prior firmware a 12-second standing flat fade (WGN,
  fade depth 20 dB, 1 Hz) emitted 514,102 AdjustS_N calibration blocks (151.9 MB of
  serial output). After the fix, a 45-second standing flat fade emitted zero blocks
  (0 bytes), and all four interleaved STATUS reads parsed cleanly, reporting Rev 2.05,
  DEBUG=OFF, FADE_DEPTH_DB=20, and BUILD=7037038@20260921T061316Z.
• Operator-initiated blocks are preserved: standalone MPP:25 prints exactly one block;
  a serial S:N change mid-fade (WGN:30) prints exactly one block and then goes quiet;
  the RESET boot banner prints exactly one block.
• The boot banner and STATUS report Rev 2.05 and 7037038@20260921T061316Z; the exact
  nine-command program ends with live MPP and mode-3 tap initialisation.
• The Butler fade-certification gate was re-run on the new build: FADECERT MPG returned
  PASS with all five checks true and build_matches_expected=true; the MPG profile
  measured envelope std 7.14 dB and a 23.6 dB p95–p05 span with 5 downward −3 dB
  crossings, while the matched WGN control measured 0.05 dB std with zero crossings.
• RESET re-enumerated cleanly and the device was restored to neutral WGN defaults before
  the Butler lock was released.