fix(deps): stop mio 0.6.23's null-deref UB check aborting Windows tests

[phil-opp]

mio 0.6.23 (reached via mio-extras → rustdds/ros2-client) computes struct
field offsets with the pre-offset_of! idiom:

// mio-0.6.23/src/sys/windows/selector.rs:470
&(*(0 as *const $t)).$($field).+ as *const _ as usize

That is a literal null-pointer dereference. Its Windows IOCP completion handlers
(overlapped2arc!, 6 call sites across sys/windows/udp.rs and tcp.rs) run it on
every completed UDP/TCP operation, so with debug-assertions on, rustc's
null-pointer check fires a non-unwinding panic — uncatchable, aborts the process:

thread 'RustDDS Participant 0 event loop' panicked at
  mio-0.6.23\src\sys\windows\udp.rs:401:25:
null pointer dereference occurred
thread caused non-unwinding panic. aborting.
error: test failed, to rerun pass `-p dora-ros2-bridge --lib`
  process didn't exit successfully: ... (exit code: 0xc0000409, STATUS_STACK_BUFFER_OVERRUN)

In the Windows nightly this lands the moment
transport::tests::context_new_dds_uses_requested_domain brings up a real DDS
participant, taking the rest of the dora-ros2-bridge lib tests with it. It also
means any debug build that actually receives DDS traffic on Windows aborts —
release builds are unaffected because debug-assertions is off there.

Not a regression from a dependency bump, and not new: it has been latent since that
test was added on 07-21. The 08-03/08-04 nightlies failed earlier, at
cargo check --all, on unrelated Windows-only compile errors; once those were fixed
the job got far enough to reach this.

Why not just upgrade

Checked every published version in the crates.io index — mio 0.6 cannot be upgraded
away:

• mio 0.6.23 (2019) is the last 0.6.x.
• mio_06 = "^0.6.23" is a non-optional direct dependency of every published
  rustdds, 0.14.0 included.
• ros2-client 0.8.1 / 0.9.0 / 0.10.0 each depend on mio ^0.6.23 directly.
• mio-extras 2.0.6 requires mio ^0.6.14 on top.

So the ros2-client 0.10 / RustDDS 0.13.1 port in #2854 would not have fixed this.

The only way to remove the UB rather than the check is to patch mio itself — a
one-line offset_of! → ::std::mem::offset_of! change, which I verified drops the
inserted assertions in mio's Windows MIR from 57 to 0. It has to be a git source:
a vendored path patch loses --cap-lints allow and mio 0.6 then fails to build on
modern rustc. That was weighed and deferred — a forked git dependency is more
supply-chain surface (cargo-deny / audit / license jobs, and a divergence from what
crates.io consumers resolve) than this nightly failure justifies.

What this does

Opts the one dependency out of debug assertions, restoring the behavior mio 0.6 was
written against. The version is pinned in the profile spec on purpose: if
mio 0.6.23 ever does leave the graph, cargo check warns that the spec matches
nothing, which is the cue to delete the block.

Verified on rustc 1.97.1 (the pinned CI toolchain) with a minimal two-crate
reproduction of mio's macro: debug build aborts with the identical message, the
per-package override makes it pass, release was always fine. Confirmed in this
workspace that the spec matches mio v0.6.23 and not mio 0.8.11/1.2.2, and that a
wrong version warns.

Known limitation: workspace profile overrides don't reach downstream consumers, so
someone depending on dora-ros2-bridge from crates.io and building in debug on
Windows still hits the abort. Fixing that needs an upstream RustDDS change.

PR CI is Linux-only, so the real confirmation is the next Windows nightly.

Fixes #3091

[trunk-io]

😎 Merged successfully - details.

[phil-opp]

🤖 Fully automated review by Claude. No human has verified these findings — treat them as advisory.

No issues found. The [profile.dev.package."mio:0.6.23"] override is valid Cargo (a version-qualified package key), scoped strictly to the offending dependency and version, and only affects dev-profile debug assertions — release builds already run without them. This restores the behavior mio 0.6 was written against without patching the crate.

---

Generated by Claude Code