Bad length field is reported to the sender, not to the receiving application

I ran a three-node chain on vsomeip 3.7.0 (Boost 1.74.0, loopback, SD disabled): a sender S, a gateway that offers one service and forwards to a second one, and a receiver R. S sends a valid SOME/IP message and appends extra bytes to the same datagram, past what the Length field declares. Three runs, identical every time.

| datagram | declared body | trailing | reached the handler | came back to S |
|---|---|---|---|---|
| 24 B | 16 B | 0 | yes, 8-byte payload | nothing |
| 56 B | 16 B | 32 B | yes, 8-byte payload | `MT_ERROR` / `E_MALFORMED_MESSAGE` |
| 88 B | 16 B | 64 B | yes, 8-byte payload | `MT_ERROR` / `E_MALFORMED_MESSAGE` |
| 4651 B | 16 B | 4627 B | no, dropped | nothing |

So the stack does notice. `udp_server_endpoint_impl` logs `Unreliable SomeIP message with bad length field`, and the same branch calls `on_error`, which reaches `endpoint_manager_impl::on_error` and then `routing_manager_impl::send_error`. That builds an `MT_ERROR` and transmits it back to wherever the datagram came from. I only saw it because I kept the sender's socket open instead of closing it after `sendto`:

```
service=0xa5a5 method=0xa5a5 length=8 type=MT_ERROR return=E_MALFORMED_MESSAGE
```

The service and method read `0xa5a5` because they're pulled out of my own filler bytes, which is what `send_error` does when the trailing data doesn't parse as a header.

My question is about the direction rather than the detection. The message handler received the valid first message and has no way to learn that the same datagram also carried bytes that failed to parse. The party that does get told is the sender, which already knows what it put on the wire. Is that deliberate, maybe for robustness against a peer that pads, or is it just where the code ended up?

I'm not reporting a vulnerability and I don't believe there is one here. The first message is parsed exactly as its Length field says, which is correct behaviour. What I'd like to know is whether surfacing that condition to the application, through a return code, a callback, or a strict mode, is something you'd consider in scope.

The 4651-byte row is a different story and I'm not asking about it: it exceeds `VSOMEIP_MAX_UDP_MESSAGE_SIZE` and gets dropped before any of the above, which is loud and easy to diagnose.

Happy to share the harness and the raw logs if they're useful.

Start by tracing the bad-length branch in udp_server_endpoint_impl, then follow on_error through endpoint_manager_impl::on_error and routing_manager_impl::send_error. Use the reported three-node harness or raw logs to confirm the existing direction of MT_ERROR; done means the issue's requested application-facing behavior is specified and covered by a reproducible test.

Written by the indexing model from the issue text.