v0.152.0 + felhom-samba 1.1.0 — mDNS for macOS, and the card stops offering a dead form

Capture on the box disproved the first theory: macOS DOES send a correct NBNS
query for <NAME><20> and nmbd DOES answer it correctly in 140us (flags 0x8580,
RCODE=0, right address) - macOS just never acts on it. NetBIOS there feeds
legacy browsing, not smb:// URL resolution, so the bare name can never work on
a Mac and nmbd was never the broken part.

felhom-samba 1.1.0 adds avahi + dbus, with avahi-daemon.conf and the _smb._tcp
service file templated from FELHOM_SERVER_NAME so a rename re-advertises. Both
daemons are non-fatal on failure - a discovery gap must not become an outage.

v0.151.0's card offered smb://<NAME> for Mac, which is exactly the dead form;
now smb://<NAME>.local. Windows keeps the flat \\<NAME>, which nmbd serves
correctly. Red-proofed both directions.

NOT claimed: Finder-sidebar discovery - published and answering on the wire,
but not observed working on the test Mac. Recorded OPEN.

TestRenderSambaCompose pinned the literal 1.0.0 tag, so an image bump read as a
renderer regression; now derives from SambaImage and asserts non-:latest.

controller/infra-images/samba/Dockerfile

@@ -9,13 +9,28 @@
 #             in Explorer but the double-click fails 0x80070035 (no flat-name resolution);
 #             nmbd is what makes \\<NAME> resolve + mount (S4b, proven live).
 #   - wsdd  : WS-Discovery, so the box appears in Windows Explorer's Network view.
+#   - avahi : mDNS/Bonjour (v1.1.0) — THE macOS path. Windows and macOS do not share a
+#             discovery mechanism, and nmbd does not cover the Mac: captured live on
+#             2026-07-20, macOS broadcasts a correct NBNS query for FELHOM<20>, the box
+#             answers correctly in 140us (flags 0x8580, RCODE=0, the right address), and
+#             macOS REFUSES TO ACT ON IT — no TCP follows. NetBIOS feeds legacy browsing
+#             there, not smb:// URL resolution. With mDNS, `smb://<NAME>.local` connects
+#             immediately — PROVEN live from a Mac on 2026-07-20.
+#             NOT proven: automatic appearance in the Finder sidebar. The _smb._tcp record
+#             is published and answers browse queries on the wire, but the test Mac's
+#             sidebar stayed empty (it had no Network/Bonjour section shown at all, which
+#             is a Finder Settings -> Sidebar toggle). Treat sidebar discovery as an OPEN
+#             question, not a shipped feature.
+#             Evidence: felhom.eu/documentation/audits/DIAG-sharing-2026-07-20.md.
 FROM alpine:3.21@sha256:48b0309ca019d89d40f670aa1bc06e426dc0931948452e8491e3d65087abc07d
 
 # samba = smbd + nmbd + smbpasswd/testparm (meta-package proven installable in the spike);
-# wsdd = WS-Discovery daemon; tini = a proper PID1 to reap nmbd/wsdd and forward signals.
-RUN apk add --no-cache samba wsdd tini \
+# wsdd = WS-Discovery daemon; tini = a proper PID1 to reap nmbd/wsdd/avahi and forward signals;
+# avahi + dbus = mDNS/Bonjour (avahi-daemon talks to the system bus, so dbus is not optional).
+RUN apk add --no-cache samba wsdd tini avahi dbus \
     && rm -rf /var/cache/apk/* \
-    && rm -f /etc/samba/smb.conf
+    && rm -f /etc/samba/smb.conf \
+    && rm -f /etc/avahi/services/*.service
 
 # passdb on a named volume → the household SMB password survives container recreation
 # (share add/remove re-renders + `compose up -d`, which recreates the container).