Add safe serial baud discovery and rate-aware polling

[FtlC-ian]

Problem

The SPE Application Programmer's Guide for the EXPERT 1.3K-FA and 2K-FA says:

The maximum speed is 115.200 kbps and the amplifier adapts automatically lower speeds.

In practice, at least one real EXPERT 2K-FA with its built-in FTDI FT232R interface did not communicate at the server's preferred 115200 baud but did communicate at 57600. That confirms a useful fallback, but it does not establish that every 2K-FA requires a model-specific 57600 default.

Model detection cannot help bootstrap this case because the server cannot identify the amplifier until serial communication is already working.

Proposed behavior

• Keep 115200 as the preferred first attempt because it is the vendor-documented maximum.
• When no valid protocol response is received, probe a conservative ordered list of supported rates, initially:
  • 115200
  • 57600
  • 38400
  • 19200
  • 9600
• Probe using only a harmless GET STATUS request.
• Accept a rate only after receiving valid framed and checksummed responses; do not infer success from bytes merely arriving.
• Persist or clearly expose the detected rate so subsequent starts are deterministic.
• Allow an explicitly configured baud rate to bypass discovery.
• Never send button/menu actions during discovery.

Rate-aware runtime behavior

The normal polling schedule may exceed the useful bandwidth of lower rates, especially when transferring full LCD frames. After discovery:

• calculate or select polling intervals appropriate for the detected rate;
• avoid building an unbounded request/response backlog;
• expose the effective baud rate and effective polling cadence in settings/runtime diagnostics;
• warn when the connection falls below the preferred rate.

Suggested warning:

Connected at a fallback serial rate. Control remains available, but display and status updates may be slower. If this was unexpected, check the USB cable/interface, amplifier firmware, and physical connections.

The warning must not claim that a slower detected rate proves a dirty connector or defective cable; firmware, amplifier vintage, host/interface behavior, and autobaud acquisition may also be responsible.

Acceptance criteria

• Discovery is covered with fake-port tests for success, timeout, malformed frames, checksum failures, and fallback ordering.
• A wrong-rate candidate cannot trigger an amplifier action.
• The selected rate is visible through the API and UI.
• Poll scheduling remains bounded at every supported detected rate.
• Existing explicit serialBaudRate configurations remain compatible.
• Documentation records 57600 as confirmed working on at least one real 2K-FA without generalizing that result to the entire model line.

[FtlC-ian]

v0.3.0 addresses the immediate correctness piece: all fallback button/wake transports now honor the explicitly configured serialBaudRate, and the README/UI/install guide document the reported 2K-FA 57600 setup without generalizing it to every unit. Safe autobaud discovery and rate-aware polling remain future work under this issue.

[FtlC-ian]

Current release status: v0.3.1 keeps 115200 as the preferred/default rate and describes 57600 only as confirmed on one field installation. Explicitly configured serial rates are honored by the normal reader and fallback button/wake transports.

This issue remains intentionally open because automatic safe discovery, checksummed candidate validation, persisted/effective-rate reporting, and rate-aware bounded polling have not shipped.

[FtlC-ian]

Justin's Expert 2K-FA packet captures add two separate findings relevant to this issue:

1. The existing both scheduler can starve either poll type after delayed reads because missed half-interval slots advance the phase arithmetically. That deterministic client bug is tracked separately in Fix both-mode poll scheduler starvation after delayed reads #38 and does not require weakening any safety gate.
2. Through an SPE-LAN-UNIT virtual-COM transport at 57600 baud, the documented 55 55 55 01 90 90 status request received no status frame and no ACK in bounded both and status-only captures. Display polling, DISPLAY ACKs, and OPERATE commands remained bidirectional and functional. This makes protocol-native fan-policy gates unreachable on that transport, but it does not prove whether the cause is the LAN unit, amplifier firmware Rel.08_06_26_A, or their combination.

The next evidence request is a read-only direct-USB versus LAN-unit status-only A/B. Until that exists, PR #34 remains blocked and the server will continue failing closed rather than treating display-derived state as protocol-native status.