R-67: the NAS share appears in FileBrowser (v0.160.0)

Network shares bind their share ROOT :rslave into FileBrowser — no
skeleton, no userdata scoping, nothing written toward the NAS. Gate is
the stub classifier (stub ⇒ excluded from mounts AND sources — an
exposed stub swallows uploads the real mount later shadows); idle autofs
is healthy and included. Drives byte-identical. Add/remove trigger the
debounced sync. Phase-0 probe on demo-hp: GO (in-container rslave access
wakes the idle trigger). Red-proofs A + B run.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UuFPHmHNrCJj1VhY6QdDMU

CHANGELOG.md

@@ -1,5 +1,39 @@
 ## Changelog
 
+### v0.160.0 — R-67: the NAS share appears in FileBrowser (2026-07-22)
+
+No agent coupling; MinAgent unchanged. Origin: the R-64 pairing drill — the share said „Elérhető"
+and the customer had no way to BROWSE it; FileBrowser synced drives only.
+
+**Phase-0 probe (GO, demo-hp, 2026-07-22):** with the Felhom-Share automount confirmed IDLE (autofs
+trigger in /proc/mounts, no cifs mount), `docker run --rm -v …/Felhom-Share:/probe:rslave alpine ls
+/probe` listed the real share content and left cifs mounted — an in-container access through an
+rslave bind DOES wake the idle trigger, one namespace further than the spike's in-guest proof. The
+design shipped as specified, no fallback fork needed.
+
+**The change:** `syncFileBrowserMounts`' path loop is extracted into the pure
+`buildFileBrowserPaths` (deps injected: mount probe / FS classifier / skeleton fn / logger), which
+now returns BOTH the mount lines and the config source set so the two can never disagree. Network
+shares get their own branch:
+
+- bind = the share ROOT, `…/<name>:/srv/<name>:rslave` — `:rslave` is load-bearing (host-side
+  automount wake / idle-unmount events propagate into the running container);
+- NO `EnsureUserdataSkeleton`, no userdata scoping — nothing is ever written toward the NAS;
+- the drive-absent gate does NOT apply (an idle automount is healthy and would be skipped
+  forever); the gate is the `stub` classifier verdict instead — **the data-safety wrong case**:
+  exposing a local stub dir lets a customer upload files the real mount will later shadow, so a
+  stub share is excluded from mounts AND sources this pass with a WARN. autofs / network /
+  unknown / nil-classifier all include (fail open).
+- Drive behavior is byte-identical (tested: the drive line with a share present equals the
+  drives-only render; drives always stay in the source list as before).
+- NAS add-success (`runNetAdd` done) and remove (`handleNetStorageRemove`) now trigger
+  `SyncFileBrowserMounts()`; removal drops the source + mount on the next sync (F2 change
+  detection forces the recreate).
+
+Tests: `filebrowser_network_test.go` scenarios A–D. Red-proofs recorded in REPORT.md: A (network
+routed through the drive branch → the skeleton-call assertion fails with the NAS path recorded)
+and B (stub gate dropped → the stub share leaks into mounts + sources).
+
 ### v0.159.0 — R-66: the box's own address becomes visible (2026-07-22)
 
 No agent coupling; MinAgent unchanged. Controller-only, three XS legs with one theme: **the box