v0.172.0 — R-75: canonical import root, catalog-derived skeleton, import surfaces

${IMPORT_PATH} = <system namespace root>/userdata/import — ONE drop-zone per box,
on the system drive, injected at BOTH compose-env builders with NO per-drive
fallback (unresolvable leaves it unset so compose fails loudly rather than
quietly building a second, dead drop-zone).

Third BindRoot (RootImport) + Import list in BackupSpec, extended through
ValidateBackupSpec/ClassifyBinds. Load-bearing: a stale `userdata: import/<app>`
entry against the moved bind would be a WHOLE-BLOCK reject, taking the app's
mandatory hdd classification with it.

Exhaustive-root audit: resolveAbs/structuralGuard/ComputeCaptureSet/
ComputeFabBuckets now take importRoot explicitly (an import bind resolved
against hddPath would name a directory on the wrong drive); unresolvable is
refused loudly into Skipped. GetImportRoot added to both provider interfaces.

Catalog-derived skeleton: UserdataSkeleton() -> UserdataSkeletonCarry() +
BuildUserdataSkeleton(), SORTED. The carry-list makes zero-removals true by
construction (`documents` is in no catalog app but on both boxes) and is the
fresh-box floor. The sort is not tidiness: the naive map-order derivation
measured 20 distinct outputs from 20 identical runs, which with fbNeedsRecreate
is a fleet-wide FileBrowser restart loop.

One authoritative compose parser: ParseComposeUserdataMounts now delegates to
ParseComposeClassifiableBinds. Import root excluded from per-app migration.

Surfaces: FileBrowser /srv/beolvasas source; app-page "Hova tegyem a fajlokat?"
with PathEscape deep links (never QueryEscape) and class-driven copy;
data_paths: annotation with the Fork-3 asymmetry; system-owned beolvasas SMB
share refused server-side at handler AND store, button omitted in template.

Caught on the way: the sharing template's row struct was function-local, so
adding {{if .System}} would have 500'd every share row. ShareRow is now
package-level and the render test uses the handler's own type.

Tests 915 -> 949, all green. MinAgent unchanged.

controller/internal/web/storage_handlers.go

@@ -279,7 +279,7 @@ func (s *Server) registerStoragePath(where, label string, setDefault bool) error
 	// v0.66.0: create the full userdata skeleton with the shared-storage convention (2775 setgid,
 	// gid 1000) the moment a drive is registered — system drive AND additional drives. Idempotent;
 	// best-effort (a perms hiccup shouldn't block registration).
-	if err := appbackup.EnsureUserdataSkeleton(where); err != nil {
+	if err := s.ensureUserdataSkeleton(where); err != nil {
 		s.logger.Printf("[WARN] [web] userdata skeleton on %s: %v", where, err)
 	}
 	// Change 4: re-enrolling a previously-DECOMMISSIONED drive must un-retire it. AddStoragePath
@@ -890,3 +890,19 @@ func (s *Server) handleStorageEject(w http.ResponseWriter, r *http.Request) {
 	}
 	writeDiskJSON(w, http.StatusOK, true, "", res)
 }
+
+// ensureUserdataSkeleton applies the CATALOG-DERIVED userdata skeleton (R-75) to a storage path.
+//
+// It replaces the direct appbackup.EnsureUserdataSkeleton call, which used a hardcoded Go list, so a
+// new catalog app with a folder no longer needs a controller release. The derived set is merged with
+// appbackup.UserdataSkeletonCarry (which is the old hardcoded list verbatim), so the result can only
+// ever ADD — no directory this arc touches is ever removed.
+//
+// Falls back to the carry-list alone when the stack manager is not wired (setup mode / tests), which
+// is exactly the pre-R-75 behaviour.
+func (s *Server) ensureUserdataSkeleton(nsRoot string) error {
+	if s.stackMgr == nil {
+		return appbackup.EnsureUserdataSkeleton(nsRoot, appbackup.BuildUserdataSkeleton(nil))
+	}
+	return s.stackMgr.EnsureUserdataSkeleton(nsRoot)
+}