muse switch leaves empty directories behind when their last file is removed

Summary

muse switch <branch> correctly removes files that aren't part of the target branch, but does not remove directories that become empty as a result of that removal. The empty directory is left on disk and immediately shows up as untracked noise in every subsequent muse status on the branch you switched to -- even though that branch never had it.

This is the confirmed root cause of the 12 mystery empty directories found on a local ~/ecosystem/muse checkout (see #94): a proposal review (#12, feat/216-branchmeta-created-by) with a real, populated OverseerKit install (39 files under .claude/skills/, .cursor/rules/, .overseer/policy/, etc. -- commit sha256:05ad6bb82, "chore: init Overseer kit...") was checked out locally for review, then switched away from back to dev. The files correctly disappeared; the directory shells did not.

Reproduction (100% reliable, isolated sandbox, no dependency on any

real repo state)

rm -rf /tmp/muse_dir_repro && mkdir -p /tmp/muse_dir_repro && cd /tmp/muse_dir_repro
muse init --json

echo "hello" > README.md
muse code add README.md --json
muse commit -m "init" --json

# Branch A: commit a real file nested two directories deep
muse switch -c feat/scaffold --json
mkdir -p scaffold/sub
echo "content" > scaffold/sub/file.md
muse code add scaffold/ --json
muse commit -m "add scaffold files" --json

# Switch back to main, which never had this file
muse switch main --json

ls -la scaffold/sub/   # file.md is correctly gone (empty dir)
ls -la scaffold/       # sub/ is still there
muse status --json     # "untracked": ["scaffold/", "scaffold/sub/"]

Expected

After muse switch main, scaffold/ and scaffold/sub/ should not exist on disk at all -- the working tree should exactly match main's tracked state, with no leftover empty directories from the branch switched away from. muse status on main should be clean.

Actual

scaffold/ and scaffold/sub/ persist as empty directories after the switch, and immediately appear as untracked in muse status on the target branch -- permanently, until someone notices and manually deletes them (there's no automatic way to detect "this untracked directory is a switch-cleanup leftover" vs. "this is an intentional new directory a human just created").

Why this is a sharper correctness gap for muse than it would be for git

Given directories are first-class, content-addressed objects in muse (EMPTY_DIR_OID -- see docs/agent-guide.md's "Content-addressing over marker files" convention), a leftover empty directory isn't just an incidental OS artifact the way it effectively is in git (git never tracked the directory as an entity to begin with, so there's nothing to clean up in git's own data model -- any stray empty dir left behind is purely a filesystem side effect, not a tracked-state inconsistency). In muse, this produces an actual state inconsistency: the directory now looks identical to a directory a human deliberately created and simply hasn't code added yet, and nothing distinguishes the two. Git handles the analogous case (files removed by checkout leave behind now-empty parent dirs) by pruning those directories as part of checkout's working-tree sync -- muse should have at least that level of parity, and arguably a stronger guarantee given directories are real tracked objects here.

Suggested fix

During muse switch's working-tree sync step, after removing every file not present in the target branch's manifest, walk the set of parent directories of each removed file (deepest-first) and rmdir any that are now empty AND are not present in the target branch's directories list (i.e. not an intentionally-tracked empty directory on the branch being switched to). Needs to handle the case correctly where the target branch's OWN manifest legitimately wants an empty directory to exist there (via directories) -- that one should NOT be removed, only ones that have zero footprint (no files, not in directories) in the target branch.

Affected repos

Confirmed in a fresh, isolated muse init sandbox -- not specific to any one repo's history or config. Very likely affects every muse repo with branches that touch different directory structures.