Hi Kieron,
Was the first sign a backend worktree showing up as prunable in git worktree list?
Every single step here looks routine on its own. git status comes back empty because backend/ is ignored, worktreeUnchanged reads that as nothing to lose, and then git worktree remove, or the git clean -ffdx on the tracked-changes path, takes the nested repo and its uncommitted files with it, all without one warning. Nobody would flag a cleanup like that as risky, which is exactly why the loss is silent and hard to explain after the fact. That kind of quiet deletion is what I spend most of my time on now, being able to trace back what a job saw and why it decided a folder was safe to drop. Refusing whenever there is any .git entry below the root or a path in another repo's worktree list sounds like the right guard to me. How long had umbrella worktrees been getting cleaned up before you dug into storageCleanup.ts?
Sam