41accc3263
The previous heuristic ("function % 2 == 0 && pending_requests_.count(sys)")
worked in practice but was wrong in principle — SECS-II doesn't enforce
function parity, and a peer protocol violation (replying with the wrong
SxFy) would have been silently treated as a primary message.
Now PendingRequest carries the expected reply stream + function (computed
from request.stream / request.function+1 per SECS-II convention) at
send_request time. handle_data matches on all three:
it->second.expected_stream == h.stream() &&
it->second.expected_function == h.function()
If sys_bytes matches but stream/function doesn't, the Connection logs
a diagnostic ("!! unexpected SxFy for pending sys=N (expected ...)")
and treats the message as a primary so the application handler can
still respond. The pending request stays open until T3.
No behaviour change on the happy path; the demo and all 69 tests still
pass.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>