A pinned snapshot worktree survived its run: cleanup is not reached on every path, and the cache is the wrong home if snapshots are ever kept #846

snapshot.Pin creates a detached worktree per layer under ${XDG_CACHE_HOME}/devlore/snapshots/<layer>-<hash12>/
and PinAll returns a cleanup that is deferred by the caller. One got left behind:

$ ls ~/.cache/devlore/snapshots/
personal-717b3da041f8
$ git -C ~/.local/share/devlore/writ/repos/personal worktree list
…/writ/repos/personal                                  27e53171 [main]
…/.cache/devlore/snapshots/personal-717b3da041f8       717b3da0 (detached HEAD)

717b3da0 is not the current HEAD and no run today produced it; it is from an earlier run whose
cleanup did not complete — a refused deploy, an interrupted one, or a path where cleanup is not
reached. Whatever the cause, the checkout (84 MB for personal) and the worktree registration both
persist, and every later Pin at a different hash adds another beside it.

Two things

1. Cleanup must be reached on every exit — including the early returns in pinLayers and the
   refusal paths in pre-flight — or the next Pin should sweep snapshots of the same layer at other
   hashes before creating its own. The second is the robust one; the first is still right.
2. Snapshots do not belong under XDG_CACHE_HOME if they are ever retained on purpose. A cache
   is by contract something the user may delete. The question of retaining them — deployed links
   pointing at the pinned snapshot rather than the live working tree, for stability between
   upgrades, as a per-layer policy — is being considered under writ upgrade does its whole job: links added, orphans removed, stale links relinked, copies regenerated -- what the name promises #845; if it lands, snapshots move to
   the state or data home first.

Observed 2026-09-06.

Epic: #466 · Feature: #472