Fix ADAU1701 SerialInputRegister IBP override causing persistent hiss

The 2026-08-16 IBP=1 override (commit 6974095) was applied alongside a
separate, simultaneous fix to Si4684's PIN_CONFIG_ENABLE and credited
with turning static into audible music. SerialInputRegister (0x081F) is
a single register shared by every SDATA_INx pin on the ADAU1701, so the
override also applied to the ESP32 streaming input, not just Si4684's.
Live A/B testing today (DAB, FM, and ESP32 web-radio, all isolated via
mixer gain, with and without ADAU1701 DSP bypass, with and without BT
A2DP codec changes) narrowed the hiss to this one shared register.
Removing the override and leaving IBP at its compiled default (0x00)
resolved the hiss on both the Si4684 and ESP32 paths, confirmed by ear.

Also:
- Add a runtime HTTP API (GET/POST /api/bluetooth/a2dp-codec) to change
  the BT1035 A2DP codec bitmask without reflashing, used to rule out
  AAC/SBC codec choice as a contributing cause.
- Extend the ADAU1701 boot-time EQ diagnostic to read back all 6 bands
  (previously band 0 only) using the correct 5.23 fixed-point format.
- Note EEPROM persistence for ANTCAP/crystal calibration as TODO.

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

Software/docs/TODO.md

@@ -221,12 +221,20 @@ required yet) and, once a result converges, **write the result to the
 persistence, see `Eeprom24aa::writeFmAntCap`/`writeDabAntCap`) so it
 survives a reboot without a firmware reflash. `recalibrateXtal()`
 (`Si4684Driver.cpp`) already does the live re-boot-with-new-params part;
-what's missing is EEPROM persistence for CTUN/XTAL_FREQ (ANTCAP already
-persists this way — the xtal calibration should follow the same shape,
-likely a new EEPROM word address alongside the existing FM/DAB ANTCAP
-ones) and doing the FREQOFF-averaging/damping/convergence-loop logic
-in firmware (or keeping it host-side and just adding the EEPROM-persist
-step at the end — decide when picked up).
+what's missing is EEPROM persistence for **all three** crystal
+calibration parameters -- `ibias`, `ctun`, AND `xtalFreqHz` (not just
+XTAL_FREQ; confirmed explicitly 2026-08-24 that all three need to
+persist, not only the one this session happened to tune) -- plus loading
+them at boot the same way `main.cpp` already loads the saved FM/DAB
+ANTCAP into `TunerService` before the first tune. ANTCAP already
+persists this way (2 bytes/band, word addresses 0x00/0x01) — the xtal
+calibration needs its own new EEPROM word address(es) alongside those
+(ibias fits in 1 byte, ctun in 1 byte, xtalFreqHz needs 4 bytes -- 6
+bytes total, or pack more compactly if EEPROM space is tight). Also
+still needed: deciding whether the FREQOFF-averaging/damping/
+convergence-loop logic (currently in `tools/si4684_xtal_calibration.py`)
+moves into firmware, or stays host-side with just an EEPROM-persist step
+added at the end of the existing HTTP flow.
 
 Not started — explicitly deferred to a future session, noted here only so
 it isn't lost. See `docs/si4684-rf-investigation-report.md`'s 2026-08-23