…during a prebuilt update

…annot be moved aside

…ng a copy of it

Fault injection over the failure paths of activate_install_tree showed the
retained rollback tree is preserved but unreachable: no loader looks under
.staging, so a run that keeps one still leaves the user with nothing at the
install path, and nothing in the tree ever removes those trees again, so a
machine that keeps failing parks another multi-gigabyte copy every time.

  - Retry the aside-move and the rollback restore against transient Windows
    sharing violations (WinError 5/32/145), the way the Node installer's
    _replace_with_retry already does. A scanner holding a freshly extracted
    DLL clears in a second or two; without a backoff it aborted the update.
  - Copy the previous install back when the restore rename cannot run at all,
    so the choice stops being between a rename and an empty install directory.
    A linked install is never copied, because copytree follows its source root
    even with symlinks = True and that would turn a --with-llama-cpp-dir link
    into a real duplicate of a checkout this installer does not own.
  - Keep exactly one retained copy, and reclaim every retained tree once an
    activation has been confirmed, which is the one moment they are provably
    no longer the last llama.cpp on the machine.
  - Clear the read-only attribute during cleanup on Windows, where it blocks
    an unlink outright. Not on POSIX: there the permission that decides an
    unlink lives on the parent directory, so the chmod cannot help and would
    leave an unreadable directory at 0o200. The handler also refuses the
    non-removal callbacks rmtree routes through it and never chmods through a
    link or a junction.
  - Escape the install directory name before globbing the staging root, since
    it comes from UNSLOTH_LLAMA_CPP_PATH and a bracket in it would reach the
    side paths of a different install holding a different lock.

Running as root, 0o500 does not stop shutil.rmtree from deleting the
directory, so the pytest.raises fails and the finally block then raises
FileNotFoundError on a directory that is already gone. Guard with the
os.access check this file already uses for the read-only marker tests,
and only restore the mode if the directory survived.

glob.escape neutralizes * ? and [ but does not anchor the trailing *, so
the pattern for foo also matched the side paths of a co-located install
literally named foo.rollback-something: its retained rollback copy, its
failed tree and its live staging dir. A successful update of foo deleted
all three while holding only foo's lock, and that copy can be the other
install's last llama.cpp.

The comment above this glob already stated the invariant and there is
already a test for the bracket variant; this is the same invariant for
the prefix variant. Checked by the tail shape rather than a per-install
staging namespace, which would strand every tree a shipped version has
already parked under .staging.

The copytree fallback is the first and only step in this recovery that
needs free space: extraction into staging happens earlier, and everything
before the copy renames or deletes. So an ENOSPC it hits is not implied
by the activation error, and often is the only place the full disk shows
up at all.

The handler bound the recovery failure to a name the except clause then
unbound, and the raise below chains from the activation error, so
_causal_chain, which follows __cause__ ahead of __context__, never saw
it. The helper exited EXIT_FALLBACK instead of EXIT_NO_SPACE and setup.sh
began a source build needing far more room than the copy that just
failed. Swap the cause only when the activation error is not already
environment fatal and the recovery error is.

The failure-path prune kept rollback_dir on the strength of it existing,
and rollback_dir is only whatever sat at install_dir when the attempt
started. An earlier failed update can leave an unusable tree there: the
remove after a failed aside-move can raise, or the copytree restore can
die partway, and the cleanup of that same directory fails for the same
reason. The next attempt then moves that broken tree aside, keeps it, and
deletes the last known-good install as superseded.

Confirm the tree about to be retained, and fall back to the newest older
rollback that confirms when it does not. The keep set is still exactly
one tree, so the retention bound is unchanged; only which tree is exempt
has changed. When nothing confirms the behaviour is identical to before.