Redesign BT1035 RESET#/SYS_CTRL handling, add CTS/RTS diagnostics

RESET# (pin 8) is no longer driven at all: reconfigured as a floating
input relying entirely on the module's own internal pull-up per
datasheet §4.8, as a diagnostic test to rule out host-side RESET# drive
as a contributor to intermittent boot failures.

SYS_CTRL (pin 34) now performs a genuine LOW(2.5s)->HIGH power-cycle on
every resetAndInitOnce() call rather than being asserted once ever:
previously every later retry from bt1035RetryTask silently reused an
already-HIGH SYS_CTRL line without ever actually power-cycling the
module.

Added read-only diagnostics on the CTS/RTS pins (physically wired,
named in board_pins.hpp since their original definition, never
configured by any driver code, host flow control disabled) to observe
their level around the boot-banner wait, after reviewing a sibling
project's PinScope report and re-reading the datasheet's UART flow
control and PA_MUTE default-function documentation.

Across ~45 minutes of live testing after these changes, zero successful
boots were observed - inconclusive on whether this improves anything,
but each change is independently correct per the datasheet. Escalated
to Feasycom support with the full findings. Documented in the RF
investigation report and TODO.

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

Software/docs/TODO.md

@@ -158,6 +158,31 @@ Short version:
   known deviation from the historically validated design removed), not
   because this sample proved a better success rate. Root cause of the
   underlying intermittent silence is still open (see entry above).
+- **BT1035 — RESET#/SYS_CTRL redesign, CTS/RTS diagnostics, Feasycom
+  escalation (2026-08-22).** A sibling project's PinScope netlist report
+  (RESET# pulled to GND, SYS_CTRL pulled HIGH by stray resistors) was
+  checked against our own schematic and does **not** apply to us — our
+  RESET#/SYS_CTRL wiring is correct, verified via netlist. Its RF_OUT/pin
+  51 floating finding **does** also apply to us, but is a separate,
+  RF-range-only concern (datasheet documents both internal- and
+  external-antenna variants; can't tell which we have), not the cause of
+  the digital/UART boot silence. As a diagnostic test, RESET# is now
+  never driven at all (floating input, relying on the module's own
+  internal pull-up per §4.8) and SYS_CTRL now does a genuine LOW(2.5s)→
+  HIGH power-cycle on every retry attempt (previously asserted once ever
+  and left alone, meaning retries never actually power-cycled the
+  module). Also added read-only diagnostics on the previously-unused
+  CTS/RTS pins (physically wired, named in `board_pins.hpp`, never
+  configured by any driver code, host flow control disabled) — live
+  readings were perfectly stable (CTS=HIGH, RTS=LOW) across ~12 samples
+  over 30+ minutes, arguing against pure floating-noise. **Across all of
+  today's changes combined, zero successful boots were observed in
+  cumulative 45+ minutes of live testing** — inconclusive-to-negative,
+  not proof any change helped or hurt. Escalated to Feasycom support with
+  a detailed email (drafted, kept outside the repo) covering the
+  symptom, everything ruled out, the CTS/RTS open question, and the
+  antenna-variant question; paused further live experimentation pending
+  their reply rather than keep permuting timing parameters blind.
 - **Still open**: intermittent multi-second HTTP unresponsiveness under
   load; DAB signal quality still antenna-limited; 24 KB `nvs` partition
   may be undersized (`saveProfile()` `store_failed` seen intermittently,