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/appexport/fabplan.go

@@ -34,8 +34,12 @@ func (e *Exporter) computeFabPlan(req ExportRequest, mounts []string) fabPlan {
 	if !has {
 		return fabPlan{} // legacy: byte-identical v0.130.0 capture
 	}
-	hddPath := filepath.Clean(e.provider.GetStackHDDPath(req.StackName))
-	fb := appbackup.ComputeFabBuckets(binds, has, hddPath, e.provider.GetImportRoot())
+	// R-203: the shared resolver's root parameter is a NAMESPACE ROOT — that is what the off-site
+	// side has always passed (ComputeCaptureSet ← offbox_capture.go). This site passed the bare drive
+	// path, so on the system-data fallback the export's classified paths and the backup's capture set
+	// described DIFFERENT directories for the same declared bind. They now agree by construction.
+	nsRoot := filepath.Clean(e.provider.GetStackNamespaceRoot(req.StackName))
+	fb := appbackup.ComputeFabBuckets(binds, has, nsRoot, e.provider.GetImportRoot())
 
 	deselect := sliceSet(req.DeselectOptional)
 	optIn := sliceSet(req.OptInExcluded)
@@ -82,7 +86,10 @@ func (e *Exporter) computeFabPlan(req ExportRequest, mounts []string) fabPlan {
 	}
 
 	plan := fabPlan{SkipMounts: map[string]bool{}}
-	ud := appbackup.UserdataDir(hddPath)
+	// R-203: UserdataDir takes a NAMESPACE ROOT, not the drive path. Identical on an enrolled drive;
+	// one segment short on the system-data fallback, which is where the export plan then skipped (or
+	// failed to skip) the wrong directory.
+	ud := appbackup.UserdataDir(nsRoot)
 	for _, m := range mounts {
 		mc := filepath.Clean(m)
 		if mc == filepath.Clean(ud) {
@@ -116,8 +123,8 @@ func (e *Exporter) fabEstimateSplit(stackName string, est *ExportEstimate, volum
 	if !has {
 		return
 	}
-	hddPath := filepath.Clean(e.provider.GetStackHDDPath(stackName))
-	fb := appbackup.ComputeFabBuckets(binds, has, hddPath, e.provider.GetImportRoot())
+	nsRoot := filepath.Clean(e.provider.GetStackNamespaceRoot(stackName)) // R-203, as above
+	fb := appbackup.ComputeFabBuckets(binds, has, nsRoot, e.provider.GetImportRoot())
 	est.HasClassification = true
 
 	toItems := func(cps []appbackup.CapturePath) ([]FabItem, int64) {