2026.5.19 — fix device-cgroup block on /dev/mmd_*

Root cause

Docker's device-cgroup only whitelisted char-major 509:0 (/dev/eq3loop via devices:), but multimacd creates /dev/mmd_bidcos (509:2) + /dev/mmd_hmip (509:1) at runtime via mknod. Without explicit device_cgroup_rules, rfd's open() returns EPERM despite mode 644 + running as root — producing the empty Identify response string not handled: error and crash-loop.

Fix

• docker-compose.yml: device_cgroup_rules: ['c 509:* rwm'] (5 lines YAML). Also enable /dev/eq3loop:, MKNOD/SYS_MODULE/SYS_NICE caps as the lean multimacd-shim path requires.
• run.sh: substitute Log Destination = Stderr in multimacd.conf so multimacd's INFO/WARN traffic is actually visible (default Syslog is a black hole in containers without syslogd).
• docker-compose.yml build: network: host + BMCOND_VERSION: 2026.5.7 default — docker compose build now works out of the box, no external docker build --network=host needed.

Diagnostic technique

strace -e openat on rfd inside run.sh (not via docker exec, because /dev/mmd_* only exist while multimacd is up). EPERM on a char-dev as root is deterministically a device-cgroup violation, not a race — strace beats every race-timing hypothesis.

Verified

livetest_actors.sh: 3/3 BidCoS + 3/3 HmIP PASS on the rebuilt image (no DEV bind-mount overrides).