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/README.md

@@ -2350,9 +2350,9 @@ multicast that WSD/mDNS discovery needs), its configuration is a dynamic share l
 `smb.conf` (not env vars), and its share roots must ride the backup classification. It is therefore
 the **fourth protected infra stack**: traefik / cloudflared / filebrowser / **samba**.
 
-#### The image (`controller/infra-images/samba/`, `felhom-samba:1.0.0`)
+#### The image (`controller/infra-images/samba/`, `felhom-samba:1.1.0`)
 
-Our own pinned image (alpine 3.21 by digest) running **three** daemons — `smbd` (445), **`nmbd`**
+Our own pinned image (alpine 3.21 by digest) running **four** daemons (v1.1.0) — `smbd` (445), **`nmbd`**
 (NetBIOS flat-name resolution), `wsdd` (WS-Discovery), under `tini`. nmbd is not optional: the R-6
 spike proved wsdd alone makes the box *visible* in Explorer while the double-click still fails
 `0x80070035`, because WSD supplies an icon, not a name→IP mapping. The image is deliberately dumb —
@@ -2402,6 +2402,23 @@ used only as the new-folder parent. The picker endpoint is `/api/sharing/browse`
 main mux behind `RequireAuth`+`CsrfProtect` (the `/api/` subtree is routed there, not in the web
 `ServeHTTP` switch).
 
+#### Discovery is per-platform, and the two halves do not overlap (v1.1.0)
+
+| Client | Working form | Served by |
+|---|---|---|
+| Windows | `\\<NÉV>` | **nmbd** (flat-name resolution) + wsdd (Network view) |
+| macOS | `smb://<NÉV>.local` | **avahi/mDNS** |
+| Any | `smb://<IP>` | direct — always works |
+
+**A Mac cannot use the bare `smb://<NÉV>`, and nothing we ship can change that.** Captured live
+2026-07-20: macOS broadcasts a correct NBNS query for `<NÉV><20>`, nmbd answers in 140 µs with a
+textbook positive response (flags `0x8580`, RCODE=0, right address), and macOS never opens a TCP
+connection — NetBIOS there feeds legacy browsing, not `smb://` URL resolution. avahi templates its
+config and `_smb._tcp` service file from `FELHOM_SERVER_NAME` at entrypoint, so a rename
+re-advertises; both it and dbus are non-fatal on failure, because a discovery gap must never become
+a sharing outage. **Automatic Finder-sidebar appearance is NOT claimed** — the record is published
+and answers browse queries, but was not observed working on the test Mac.
+
 **„Csatlakozás a megosztáshoz" card (v0.151.0).** Shown only while sharing is enabled: the Windows
 form (`\\<NÉV>`), the Mac form (`smb://<NÉV>`), and — when derivable — the direct address
 `smb://<IP>` as the fallback for networks that do not resolve the name. The address comes from