fix(s7commplus): correlate request responses

[gijzelaerr]

Summary

• validate S7CommPlus response opcode, function, and sequence for sync and async requests
• discard a bounded number of delayed replies from older 16-bit sequences while continuing to wait for the current response
• retain protocol-defined generic ERROR replies while rejecting unrelated or future response functions/sequences
• route interleaved notifications into per-connection queues and consume SystemEvents separately
• serialize synchronous request/response exchanges to prevent wire interleaving
• report closed connections as connection errors

Real-hardware evidence

The S7-1511C trace in #872 showed a DB-read request at sequence 7 consuming the delayed protection-level reply for sequence 6. The added regression covers that ordering for both sync and async clients. PR #881 is now stacked on this branch so the combined behavior can be tested on that PLC.

Validation

• uv run --frozen pytest -q: 2087 passed, 82 skipped
• uv run --frozen pre-commit run --all-files: passed
• uv build --no-sources: passed

Fixes #833

[gijzelaerr]

@bvanelli Could you review the S7CommPlus protocol/security changes as one batch? The independent roots are #882, this PR, #887, and #885; #884 and #888 form the stacked continuation of this PR. Your earlier protocol traces and authentication reviews are especially relevant to the response correlation, integrity-ID/HMAC validation, and session-key fallback/renewal paths. Reviewing the roots first is enough; we can update the stacked branches after any findings.

[bvanelli]

LGTM, i checked some behavioural properties:

• The stale_responses resets, so an otherwise healthy subscription cannot easility be killed.
• Code repetition in _incoming_frame_opcode and _incoming_response_sequence goes through different branches, not worth generalising.
• Lock now guarantees ordering for send_request, and there is no deadlock possibility due to the timeout.