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/stacks/deploy.go

@@ -581,7 +581,7 @@ func (m *Manager) composeExecWithEnv(dir string, env map[string]string, args ...
 		cmdEnv = append(cmdEnv, fmt.Sprintf("%s=%s", k, v))
 	}
 	cmdEnv = append(cmdEnv, fmt.Sprintf("DOMAIN=%s", m.cfg.Customer.Domain))
-	cmdEnv = withPathVars(cmdEnv, env["HDD_PATH"], m.GetImportRoot())
+	cmdEnv = withPathVars(cmdEnv, env["HDD_PATH"], m.sysDataPath, m.GetImportRoot())
 	return m.composeExecCustomEnv(dir, cmdEnv, args...)
 }
 
@@ -597,9 +597,13 @@ func (m *Manager) composeExecWithEnv(dir string, env map[string]string, args ...
 // An unresolvable importRoot is left UNSET on purpose (the caller logs it): compose then fails loudly
 // on an unresolved ${IMPORT_PATH} rather than silently falling back to a per-drive path, which would
 // recreate the dead-drop-zone shape R-75 exists to remove.
-func withPathVars(cmdEnv []string, hdd, importRoot string) []string {
+func withPathVars(cmdEnv []string, hdd, sysDataPath, importRoot string) []string {
 	if hdd != "" {
-		cmdEnv = append(cmdEnv, "USERDATA_PATH="+appbackup.UserdataDir(hdd))
+		// R-203: UserdataDir takes a NAMESPACE ROOT, not a bare drive path. Passing `hdd` straight in
+		// bound <hdd>/userdata, which equals the namespace root only on an ENROLLED drive. On the
+		// system-data fallback it is one segment short, so the app wrote to a directory the off-site
+		// capture set never looked at — and the run still reported ok. Measured live on demo-hp.
+		cmdEnv = append(cmdEnv, "USERDATA_PATH="+appbackup.UserdataDir(appbackup.NamespaceRootFor(hdd, sysDataPath)))
 	}
 	if importRoot != "" {
 		cmdEnv = append(cmdEnv, "IMPORT_PATH="+importRoot)