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/backup/appbackup_bridge.go

@@ -121,6 +121,11 @@ func NamespaceRoot(drivePath string, inGuestDrive bool) string {
 	return appbackup.NamespaceRoot(drivePath, inGuestDrive)
 }
 
+// NamespaceRootFor re-exports the ONE drive-kind-aware resolver (R-203).
+func NamespaceRootFor(drivePath, systemDataPath string) string {
+	return appbackup.NamespaceRootFor(drivePath, systemDataPath)
+}
+
 func PrimaryBackupPath(nsRoot string) string {
 	return appbackup.PrimaryBackupPath(nsRoot)
 }

controller/internal/backup/backup.go

@@ -329,7 +329,10 @@ func (m *Manager) GetAppDrivePath(stackName string) string {
 // as-is; only the SSD-only system-data fallback gets the felhom-data subdir appended. This is what
 // keeps a drive-resident app's backups single-nested instead of .../felhom-data/felhom-data/... .
 func (m *Manager) namespaceRoot(drivePath string) string {
-	return NamespaceRoot(drivePath, drivePath != m.systemDataPath)
+	// R-203: delegates to the ONE expression of the rule (appbackup.NamespaceRootFor). This used to
+	// hold its own copy — `drivePath != m.systemDataPath`, without Clean on either side — while
+	// stacks.Manager.inGuest held a second copy WITH Clean. Two copies that already differed.
+	return NamespaceRootFor(drivePath, m.systemDataPath)
 }
 
 // AppNamespaceRoot returns the felhom-data namespace root for a stack's keep-side backups, resolving