Record what the FreeBSD run measured, since the comments said it was unmeasured

The fix shipped with its evidence stated honestly as read-from-source and
inferred-from-a-log, because nothing had run on FreeBSD. The job has now
run green and the three probes that shipped with it all passed, so those
comments understate what is known.

A SOCK_SEQPACKET pair on the FreeBSD 15.1 image does not keep message
boundaries and drops a zero-length message rather than delivering it.
Both were predicted from the kernel source and both now have a
measurement agreeing with the prediction.

The open question the port rested on is answered too, and favourably: a
closed SOCK_DGRAM peer is detectable on FreeBSD, so a flow's end of file
comes from the descriptor there as it does on Darwin, and the
line-protocol fallback that a negative result would have forced is not
needed.

src/native/dgram_probe.rs

@@ -325,7 +325,9 @@ fn an_empty_datagram_queued_before_the_close_is_not_read_as_the_close() {
 /// The open question this platform's arm of [`super::seqpacket`] rests on, and
 /// the counterpart of [`darwin_reports_a_closed_dgram_peer_somehow`]. The three
 /// kernels do three different things: Linux reports nothing at all, Darwin
-/// reports `ECONNRESET`, and FreeBSD has not been measured. `recv_once` accepts
+/// reports `ECONNRESET`, and FreeBSD does signal it — this probe passed on the
+/// 15.1 CI image on 2026-08-22, so the flow's end of file can come from the
+/// descriptor there and no line-protocol fallback is needed. `recv_once` accepts
 /// either `ECONNRESET` or a zero-byte read plus `POLLHUP`, so either signal is
 /// enough and the assertion does not care which.
 ///

src/native/seqpacket.rs

@@ -16,12 +16,13 @@
 //! is not an atomic-record socket: `seqpacketproto` carries no `PR_ATOMIC` and
 //! shares its send and receive handlers with `SOCK_STREAM`, so consecutive
 //! messages coalesce and a zero-length message is queued nowhere and delivered
-//! never. **This was read out of the FreeBSD kernel source and inferred from a
-//! CI log; nobody has run it on FreeBSD.** What was observed is a CI run in
-//! which the zero-length-message test hung until the job was killed and five
-//! boundary tests failed within 360 ms, which is the shape the source predicts.
-//! The probes in [`super::dgram_probe`] are what would turn that into a
-//! measurement, and they have not been run on FreeBSD either.
+//! never. **Measured on the FreeBSD 15.1 CI image on 2026-08-22**, by the two
+//! probes in [`super::dgram_probe`] named for it: a `SOCK_SEQPACKET` pair there
+//! does not keep message boundaries, and it drops a zero-length message instead
+//! of delivering it. The reading of the kernel source came first and the
+//! measurement agreed with it; before that run the mechanism was inferred from
+//! a CI log in which the zero-length-message test hung until the job was killed
+//! and five boundary tests failed within 360 ms.
 //! Everything else this module needs works on both: `SCM_RIGHTS` is supported,
 //! `AsyncFd` is backed by kqueue, and a connected `SOCK_DGRAM` pair keeps
 //! message boundaries and delivers an empty datagram, which `SOCK_SEQPACKET`