fix: harden transport request matching against late RX

[sKuhLight]

Summary

This addresses the cache-rebuild desync path seen in the Axis / ForgeFX traces.

The trace showed that full preset dumps can complete quickly when isolated, but normal Axis usage was producing repeated fn=0x01 / fn=0x0d cross-consumption:

• a request times out with no matching frames,
• its late reply arrives during the next request,
• the next request quiet-completes with match=false,
• its real reply then poisons the following request.

The existing serial and MIDI transports serialized TX, but request RX handlers still accepted every inbound frame and used quiet completion after unrelated frames. That allowed stale frames to end the wrong request early.

Changes

• For serial and MIDI request() calls with a match predicate:
  • unrelated frames no longer quiet-complete the active request,
  • the request resolves only on a matching frame or hard timeout,
  • after hard timeout, the transport stays subscribed for one quiet window and drains/logs late RX before releasing the queue.
• Keeps old quiet-gap behavior for requests without a matcher.
• Adds explicit timeout and late-RX warnings so the log shows transport desync instead of silently misrouting frames.

Why this is the smallest robust fix

This does not assume full preset dump is slow. It prevents the observed response desynchronization at the shared transport layer for both serial and MIDI, which is the common failure surface for cache rebuild, meter polling, scene polling, status polling, and dump reads.

Notes

This is not a complete exclusive scan-mode implementation yet. The next hardening step should pause non-essential pollers during library-cache rebuild, especially meter / CPU / scene / channel edit-watch traffic. However, this patch removes the most dangerous behavior: late replies being consumed by the next request.