Context
`runtime::recv_loop` (post-21b's run-loop extraction) ignores the `ReceivedDatagram::truncated` flag returned by `TransportSocket::recv_from`. Backends that surface truncation honestly (the embassy-net adapter today; the tokio backend after #119) won't be observable from the server side.
Goal
After the `recv_from` returns, inspect `datagram.truncated` and emit a `tracing::warn!` (with the source address, byte counts, and which socket — unicast vs SD multicast) when it is `true`. The datagram should still be processed: a truncated SOME/IP header parse will fail naturally and emit its own `warn!`, but pre-flagging the truncation lets operators correlate parse failures with the upstream cause.
Triggering condition
Independent of #119 — the embassy-net backend already produces truthful `truncated: bool` and the warn would fire there.
Context
`runtime::recv_loop` (post-21b's run-loop extraction) ignores the `ReceivedDatagram::truncated` flag returned by `TransportSocket::recv_from`. Backends that surface truncation honestly (the embassy-net adapter today; the tokio backend after #119) won't be observable from the server side.
Goal
After the `recv_from` returns, inspect `datagram.truncated` and emit a `tracing::warn!` (with the source address, byte counts, and which socket — unicast vs SD multicast) when it is `true`. The datagram should still be processed: a truncated SOME/IP header parse will fail naturally and emit its own `warn!`, but pre-flagging the truncation lets operators correlate parse failures with the upstream cause.
Triggering condition
Independent of #119 — the embassy-net backend already produces truthful `truncated: bool` and the warn would fire there.