Remove or wire Syntonia's inert timing configuration

[forkwright]

Finding

Syntonia exposes a serde-serializable configuration tree for Baofeng timing, retries, serial timeouts, and hardware-probe timeout. Its module documentation says these values are tunable through TOML and agent knowledge-store overrides and that callers can thread one SyntoniaConfig down.

No production code consumes any of those types or fields. The actual protocol and detector continue to use independently hardcoded constants with the same default values. The configuration can be serialized and tested, but it cannot alter radio behavior.

Verified against main c8e671845adca3e5b57a205d08aca31eadbc6000.

Evidence

• crates/syntonia/src/config.rs:1-13 says timing/retry parameters are discoverable and tunable via TOML / agent overrides.
• config.rs:19-126 defines BaofengTimingConfig, HardwareProbeConfig, and top-level SyntoniaConfig, including defaults for 10 ms inter-byte delay, 50 ms post-ACK delay, 2 s identify retry delay, 1.5 s read timeout, 3 retries, and a 500 ms probe timeout.
• A workspace-wide source inventory on this exact revision finds SyntoniaConfig, BaofengTimingConfig, and HardwareProbeConfig only in config.rs, their lib.rs re-export, and their own tests. There is no production constructor or operation accepting them.
• crates/syntonia/src/baofeng/constants.rs:88-111 independently owns the same live 10 ms, 50 ms, 2 s, 1.5 s, and 3-retry values used by the protocol driver.
• crates/syntonia/src/hardware/detect.rs:100-105,169-178 independently hardcodes a 500 ms probe timeout and 9600 baud in the real detector.
• The config tests prove only serde/default round trips; they do not show a non-default value changing a protocol sleep, retry budget, port timeout, or detector behavior.
• cli: configuration is loaded then discarded, so AKROASIS_* env vars abort unrelated commands #461 owns a different inert configuration surface in the top-level CLI. No issue owns this Syntonia library configuration.

Why this matters

The public API and documentation claim operator-adjustable hardware behavior while the implementation is fixed. An agent or future caller can construct a valid non-default SyntoniaConfig and reasonably believe slower cables, USB hubs, or firmware can be accommodated, while every operation continues with the constants.

The duplicated defaults also create two owners: a future correction may update the apparent config while leaving hardware unchanged, or update the protocol constants while config serialization still advertises the old value.

This is over-engineering and declared-vs-actual drift at once: a complete configuration abstraction exists before a consumer, and its presence obscures the real hardcoded policy.

Desired correction

Choose one honest state:

1. Wire it: pass configuration into the Baofeng protocol/session and hardware detector, remove the duplicated behavioral constants, and prove non-default values alter observable retry/timeout/delay behavior; or
2. Remove it: delete the unused config types, TOML dependency/surface, and claims of tunability until a real caller requires them.

Protocol invariants such as opcodes, memory ranges, block sizes, and forbidden calibration addresses remain constants; only behavioral tuning belongs in configuration.

Done when:

• every retained Syntonia config field has a production read site;
• one source owns each timing/retry/probe default;
• tests demonstrate at least one non-default timing and retry value reaches the operation it configures;
• no public docs claim TOML/agent tunability that the runtime ignores; and
• the fix is not another adapter that constructs config and then discards it.