Fix FTMS control point handling

[antomanc]

Fixes the pre-existing control point issues documented in #1's validation notes, plus unsolicited broadcast of failure responses.

• Request Control was never sent to the trainer: the write in connectToRealTrainer ran before realConnected = true, so writeRealControlPoint declined it. Moved after the flag.
• Response opcode matching: real CP responses whose opcode does not match the pending one (e.g. the trainer's Request Control reply) are ignored instead of completing the pending transaction.
• Trainer disconnect: in-flight and queued commands now fail immediately with Operation Failed to their originating clients instead of leaving apps waiting.
• No broadcast responses: a timeout/failure with no originating client (serial CLI command, or an app that left mid-transaction) was indicated to every connected client, including Garmin. Now it is only stored.
• Per-client coalescing: the queue coalesces only within one client, so a second app's command no longer silently replaces the first's (which never got a response).

Validation

• bash tests/run.sh: PASS, with new assertions for each fix (verified they fail against the old firmware).
• ASan + UBSan: PASS (detect_leaks=0).
• CI compile against ESP32 3.3.12 / NimBLE 2.5.1.
• Hardware not tested. The behavior change to watch on the D100 is the Request Control write at connect, which is new in practice.

https://claude.ai/code/session_01Dgkv5W86Zhd8Rv27uCE3rj