Fix undecodable function-code exception identity

[sankalpsthakur]

Summary

When the server cannot decode a request function code (unassigned/reserved FC or serial noise), ServerRequestHandler.callback_data was building the exception response with two bugs:

1. Hardcoded function code 40 (0x28) → every undecodable request produced exception FC 0xA8, unrelated to the request.
2. transaction_id left at 0 → TCP clients correlating in-flight requests by transaction id could not match the response.

last_pdu is cleared at the start of framing, so the framer now attaches the already-decoded MBAP/RTU transaction_id and dev_id to the ModbusIOException. The server uses those attributes on the exception path, and builds ExceptionResponse(0x00, ILLEGAL_FUNCTION, ...) instead of the unrelated 40.

This matches maintainer guidance on #2990: echo transaction id, use 0x00 rather than inventing a function code from garbage.

Validation

pytest test/server/test_requesthandler.py  # 8 passed
pytest test/framer/                        # 279 passed
pytest test/transaction/test_transaction.py # 44 passed

New unit coverage:

• framing attrs echoed on undecodable path
• missing attrs fall back safely to zeros
• real socket frame with unknown FC 0x09 echoes MBAP tid 0x1234

Fixes #2990

AI/LLM disclosure

• AI coding tools (including Grok and/or Codex agent-assisted editing) were used to help draft or modify code and this PR description.
• I reviewed the complete change, understand the reasoning, and ran the reported local tests before submitting.
• This submission is original work of authorship under the project CLA / contributor terms; AI output was not pasted unreviewed.

[janiversen]

VERY nice way to solve the problem!

Feel free to search for ModbusIOException, I am pretty sure there are a number of places where transaction id and/or function code is known.

LGTM, thanks