test(relay): mesh_demo echo test flaky under parallel suite — passes standalone, fails full-suite on clean main

`api::mesh_demo::tests::demo_join_forwarded_arm_round_trips_echo` fails under the full parallel suite but passes standalone, on clean `main` (7e34bee6), reproduced twice each way:

```
# fails
cargo test -p buzz-relay --lib
# test api::mesh_demo::tests::demo_join_forwarded_arm_round_trips_echo ... FAILED
# test result: FAILED. 719 passed; 1 failed; 27 ignored

# passes
cargo test -p buzz-relay --lib demo_join_forwarded_arm_round_trips_echo
# test result: ok. 1 passed; 746 filtered out
```

Environment: macOS (Darwin 25.3.0, M-series), default test parallelism. Behavior is consistent across runs and across two checkouts (main and a feature branch with no relay changes), so it looks like inter-test resource contention (port/state shared with another test in the binary) rather than machine-specific breakage. Same family as #2369.

Not blocking anything on my side — filing since it surfaces as a false red in any full local `cargo test -p buzz-relay --lib` run.

Start by running `cargo test -p buzz-relay --lib` and the filtered `demo_join_forwarded_arm_round_trips_echo` test, then inspect `api::mesh_demo::tests::demo_join_forwarded_arm_round_trips_echo` and compare the related investigation in #2369. Trace which port or shared state overlaps with other tests. Done means the full parallel library suite passes reliably while the test still passes standalone.

Written by the indexing model from the issue text.