audit(Q1c): NAS automount trigger does NOT survive a guest reboot (empty-dir FAIL) + follow-up

Supervised live proof on the demo (agent 0.82.0 + controller 0.115.0): after pct reboot 9201 the
autofs trigger does not re-propagate into the guest; an in-guest access sees an empty dir and does
not trigger the host mount. Root cause: shared->slave propagation + no agent network-mount reassert
on guest reboot. FAIL protocol honored (nothing repaired live); fix spec'd in backlog.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PSK5g6qYLknKj8u3QAFEr6

documentation/audits/SPIKE-nas-dsm-2026-07-11.md

@@ -59,6 +59,45 @@ the UI invokes — anti-F9).
   (192.168.0.180:/mnt/5_hdd/felhom-data, health ok) — untouched by this spike; it is the Part E
   (Q1c restart) subject.
 
+## Q1c — NAS automount trigger survival across a guest restart: **FAIL (the dangerous empty-dir case)**
+
+**Supervised (operator GO 2026-07-11), on the fully-updated stack (agent 0.82.0 + controller
+0.115.0), using the operator's own `nas-media` share (read-only).** This closes the open Q1c item
+from SPIKE-nas-verify-2026-07-11 §Q1.
+
+**Method + result:**
+1. Pre-state: `nas-media` idle (host autofs trigger active-waiting; **the trigger WAS visible in the
+   guest's /proc/mounts**, having propagated when the automount was enabled while the guest ran);
+   apps healthy.
+2. `pct reboot 9201` (the sudoers-granted verb).
+3. Post-boot, **no access yet** → `pct exec 9201 -- grep nas-media /proc/mounts` = **NO_GUEST_TRIGGER**
+   (the host trigger is intact + active, but it did NOT re-propagate into the guest's fresh namespace).
+4. In-guest `ls /mnt/felhom-drives/nas-media` → **an EMPTY directory** (`nobody:nogroup`, just `./..`)
+   and the access **did NOT trigger the host mount** (no nfs4 host-side afterward). This is exactly
+   the WRONG outcome the June spike flagged: a media app (jellyfin/*arr) restarting after a guest
+   reboot sees an **empty library**, not the NAS content — and an app that "cleans up" a
+   suddenly-empty library could destroy metadata.
+5. Apps recovered healthy (controller/traefik/cloudflared/filebrowser Up); the controller's NAS list
+   still reports `nas-media` **health: idle** because it reads the HOST automount state — so the UI
+   looks fine while the guest cannot actually reach the share (a silent, misleading gap).
+
+**Root cause:** `mp8 /mnt/felhom-drives` is `shared` (host) → `shared,slave` (guest). Slave
+propagation only carries mount events that happen AFTER the slave relationship is (re)established.
+The host's autofs trigger for `nas-media` was mounted BEFORE the guest's post-reboot bind, so it is
+not present in the guest's new namespace; and the agent has **no network-mount reassert on guest
+reboot** (no `netmount`/reassert lines in the boot journal) — unlike the drive path's
+`ReassertGuestBinds`.
+
+**FAIL protocol honored — NOTHING repaired live.** State left as found: the `nas-media` host
+automount stays configured + active; the guest sees the empty bind dir until the share is re-added
+(remove+add re-runs `EnsureNetworkMount`; the fresh `enable --now` propagates the trigger into the
+running guest) or an agent-side reassert lands. **Follow-up task** (evidence = this section):
+felhom-agent should re-propagate/re-establish network automounts into the guest after a guest
+restart — mirror `ReassertGuestBinds` for the network-storage class (a `ReassertNetworkMounts` on
+the guest-reboot path). Until then, document that a customer guest reboot requires re-touching NAS
+shares, and consider having the controller's per-share health cross-check the GUEST-visible mount,
+not only the host automount, so the UI stops showing idle/ok for a guest-unreachable share.
+
 ## Teardown — verified
 
 `dsmsmb`/`dsmnfs` removed via the real remove endpoint (list shows only `nas-media`); felhom-pve: