fix(net): don't trust cmsg_len past the end of a truncated control buffer

[xrl]

Fixes #1683.

On macOS, recvmsg truncates control data to fit the RecvAncillaryBuffer but leaves cmsg_len untruncated, so AncillaryDrain::advance underflows the remaining length, the drain in Drop panics again and the process aborts; with overflow checks off, cvt_msg instead slices past the buffer and yields OwnedFds read from uninitialized memory. Messages now yields the buffer space at each header alongside it, advance clamps cmsg_len to that, and cvt_msg rounds SCM_RIGHTS payloads down to whole descriptors.

• Linux is unaffected: scm_detach_fds adjusts cmsg_len, so the clamp is a no-op there.
• FreeBSD delivers none of a truncated message's payload, so the test checks that every descriptor it gets back is one of the sockets sent, not how many.
• Not every environment CI runs in reports CTRUNC, so the test doesn't assert on it.

Disclosure: this change and its test were written by an AI coding agent (Claude, Anthropic) at the direction of @xrl, who reviewed the diff. Please review it with that in mind.

Run on macOS 15.6, aarch64, rustc 1.98.1: cargo test --features=all-apis --test net (45 pass; the new test aborts with SIGABRT against main), cargo test --release --features=all-apis --test net truncated, cargo clippy --features=all-apis --all-targets, cargo fmt --all --check.