R-203: the app and its backup look in the same directory — one resolver, every caller

appbackup's path helpers take a NAMESPACE ROOT. Five call sites passed a bare DRIVE path.
On an enrolled drive the two coincide, so nothing showed; on the system-data fallback they
differ by exactly the felhom-data segment, and the app then bound a directory the off-site
capture set never looked at -- while the run reported ok. Measured live on demo-hp: the app
wrote to /mnt/sys_drive/userdata/media/books, the capture set looked for
/mnt/sys_drive/felhom-data/userdata/media/books.

THE RULE NOW HAS ONE EXPRESSION. appbackup.NamespaceRootFor / IsEnrolledDrive encode the
drive-kind comparison; backup.Manager.namespaceRoot and stacks.Manager.inGuest delegate to
it. There were already TWO copies and they differed -- the backup package's compared without
filepath.Clean, the stacks package's with it, so a trailing slash from config would have
flipped the mode in one and not the other.

Sites routed through it:
  - stacks/deploy.go withPathVars -> ${USERDATA_PATH}   (the live defect)
  - appexport/fabplan.go + export.go                     (via a new provider method)
  - web/handlers.go FileBrowser mounts                   (latent: the system drive is
    deliberately never a registered StoragePath, so this is the identity today)

ComputeFabBuckets now receives the namespace root, which is what ComputeCaptureSet has always
received -- so the export's classified paths and the backup's capture set describe the same
directories by construction instead of by coincidence.

Tests are table-driven over BOTH drive kinds, because this survived by being invisible on the
kind that already worked. Red-proofs observed: restoring the bare-path call fails the
system-drive row with the two paths differing by /felhom-data; inverting the drive-kind
comparison fails every enrolled row.

controller/internal/appbackup/namespace_root_test.go

@@ -0,0 +1,69 @@
+package appbackup
+
+import "testing"
+
+// R-203 — the ONE drive-kind rule. Table-driven over BOTH drive kinds on purpose: this defect
+// survived because it is invisible on the kind that already worked, so a test that only covers the
+// enrolled drive proves nothing about the fix.
+
+func TestNamespaceRootFor_BothDriveKinds(t *testing.T) {
+	const sys = "/mnt/sys_drive"
+	cases := []struct {
+		name, drive, want string
+	}{
+		// Scenario B — the enrolled drive must be BYTE-IDENTICAL to pre-R-203 behaviour. The
+		// in-guest mount already IS the namespace root; appending felhom-data here would recreate
+		// the .../felhom-data/felhom-data/... double-nest NamespaceRoot's comment exists to prevent.
+		{"enrolled usb", "/mnt/felhom-usb", "/mnt/felhom-usb"},
+		{"enrolled hdd", "/mnt/felhom-drives/hdd_1", "/mnt/felhom-drives/hdd_1"},
+		{"enrolled nvme", "/mnt/felhom-drives/nvme-1tb", "/mnt/felhom-drives/nvme-1tb"},
+		// Scenario A — the system-data fallback gains the segment. This is the case that was wrong.
+		{"system drive", "/mnt/sys_drive", "/mnt/sys_drive/felhom-data"},
+		// A trailing slash is the same drive. Before R-203 the backup package's copy of this rule
+		// compared WITHOUT Clean while the stacks package's copy compared WITH it — so a config value
+		// with a trailing slash would have flipped the mode in one package and not the other.
+		{"system drive, trailing slash", "/mnt/sys_drive/", "/mnt/sys_drive/felhom-data"},
+	}
+	for _, tc := range cases {
+		t.Run(tc.name, func(t *testing.T) {
+			if got := NamespaceRootFor(tc.drive, sys); got != tc.want {
+				t.Fatalf("NamespaceRootFor(%q, %q) = %q, want %q", tc.drive, sys, got, tc.want)
+			}
+		})
+	}
+}
+
+// The rule must survive a trailing slash on the SYSTEM path too — it comes from config.
+func TestIsEnrolledDrive_CleansBothSides(t *testing.T) {
+	if IsEnrolledDrive("/mnt/sys_drive", "/mnt/sys_drive/") {
+		t.Error("a trailing slash on the system path must not make the system drive look enrolled")
+	}
+	if IsEnrolledDrive("/mnt/sys_drive/", "/mnt/sys_drive") {
+		t.Error("a trailing slash on the drive path must not make the system drive look enrolled")
+	}
+	if !IsEnrolledDrive("/mnt/felhom-usb", "/mnt/sys_drive") {
+		t.Error("an enrolled drive must report enrolled")
+	}
+}
+
+// The consequence the whole item is about: the directory an app binds and the directory the capture
+// set looks in must be the SAME on both drive kinds.
+//
+// RED-PROOF: replace `UserdataDir(NamespaceRootFor(drive, sys))` with `UserdataDir(drive)` — the
+// pre-R-203 call — and the system-drive row FAILS with the two paths differing by exactly
+// `/felhom-data`. That is production behaviour up to v0.196.0.
+func TestAppBindAndCaptureRootAgree(t *testing.T) {
+	const sys = "/mnt/sys_drive"
+	for _, drive := range []string{"/mnt/felhom-usb", "/mnt/felhom-drives/hdd_1", "/mnt/sys_drive"} {
+		nsRoot := NamespaceRootFor(drive, sys)
+		appBind := UserdataDir(nsRoot)   // what the deploy sets as ${USERDATA_PATH}
+		captureRoot := UserdataDir(nsRoot) // what the capture set resolves RootUserdata against
+		if appBind != captureRoot {
+			t.Fatalf("drive %q: the app binds %q while the backup captures %q", drive, appBind, captureRoot)
+		}
+		// And it must be the canonical location — the one EnsureUserdataSkeleton creates.
+		if drive == sys && appBind != "/mnt/sys_drive/felhom-data/userdata" {
+			t.Fatalf("system drive resolved to %q, want the canonical /mnt/sys_drive/felhom-data/userdata", appBind)
+		}
+	}
+}

controller/internal/appbackup/paths.go

@@ -32,6 +32,35 @@ func NamespaceRoot(drivePath string, inGuestDrive bool) string {
 	return filepath.Join(drivePath, FelhomDataDir)
 }
 
+// IsEnrolledDrive reports whether a drive path is an ENROLLED user-data drive (Model A: its in-guest
+// mount already IS the namespace root) rather than the system-data fallback. It is the ONE comparison
+// that decides which NamespaceRoot mode applies, and it lives here so no package re-derives it.
+//
+// Both sides are Clean'd: `/mnt/sys_drive/` and `/mnt/sys_drive` are the same drive, and a trailing
+// slash arriving from config must not silently flip the mode.
+func IsEnrolledDrive(drivePath, systemDataPath string) bool {
+	return filepath.Clean(drivePath) != filepath.Clean(systemDataPath)
+}
+
+// NamespaceRootFor is the resolver every caller should use when it holds a bare DRIVE path and the
+// system-data path — i.e. everywhere outside the backup package, which already had this rule.
+//
+// R-203: FIVE call sites passed a bare drive path straight to UserdataDir (and its siblings), which
+// take a NAMESPACE ROOT. On an enrolled drive the two coincide, so nothing showed; on the system-data
+// fallback they differ by exactly the felhom-data segment, and the app then bound a directory the
+// backup never looked at. The run still reported ok. Measured live on demo-hp 2026-08-04:
+// the app wrote to /mnt/sys_drive/userdata/media/books while the off-site capture set looked for
+// /mnt/sys_drive/felhom-data/userdata/media/books.
+//
+// THE CONTRACT, restated because four callers got it wrong and a fifth will: UserdataDir,
+// PrimaryBackupPath, RecoveryUnitPath and AppDataDir all take a NAMESPACE ROOT. If you are holding
+// something that came out of HDD_PATH or a StoragePath, it is a DRIVE path — put it through here
+// first. `UserdataDir(bareDrivePath)` still compiles and is still wrong; TestNoBareDrivePathToUserdataDir
+// is the guard that keeps the count from growing.
+func NamespaceRootFor(drivePath, systemDataPath string) string {
+	return NamespaceRoot(drivePath, IsEnrolledDrive(drivePath, systemDataPath))
+}
+
 // PrimaryBackupPath returns the root primary backup directory under a felhom-data namespace root.
 func PrimaryBackupPath(nsRoot string) string {
 	return filepath.Join(nsRoot, "backups", "primary")