bug: skills add fails with EPERM on macOS 26 -- giget cache in shared ~/.cache collides with app-data protection

[thegalexc]

Problem

cmd skills add downloads repos via giget, which defaults its cache to the shared ~/.cache/giget. On macOS 26 (Tahoe), this breaks with a confusing error:

$ cmd skills add owner/repo/path --global -f
✘ Failed to fetch "owner/repo": EPERM: operation not permitted, mkdir '/Users/callsen/.cache/giget'

Root cause: macOS Tahoe stamps directories with a com.apple.provenance xattr identifying the creating app, and denies access to processes attributed to other apps -- reportedly even when the app has Full Disk Access (see Apple Community discussion on 26.4 third-party app stamps: https://discussions.apple.com/thread/256294444). ~/.cache is shared by many CLIs across many host apps (terminal emulators, IDEs, other agents), so whichever app first created ~/.cache/giget effectively owns it. Run cmd from a different terminal app and the mkdir/stat gets EPERM. The kernel returns EPERM rather than EEXIST, so the error misleadingly suggests a local permissions problem.

Observed on v1.5.0, macOS 26 (Darwin 25.3), where ~/.cache contained a dozen subdirs unreadable by the invoking terminal (giget, codex-runtimes, huggingface, starship, ...), all created by tools running under other host apps.

Workaround (confirmed working)

giget honors XDG_CACHE_HOME:

XDG_CACHE_HOME="$HOME/.commandcode/cache" cmd skills add owner/repo/path --global -f

This works because ~/.commandcode is created by cmd itself, so the invoking app owns its provenance stamp.

Proposal

1. Point giget's download cache at a directory Command Code already owns -- ~/.commandcode/cache/giget -- instead of the shared ~/.cache/giget. Setting XDG_CACHE_HOME for the giget call (or using its cache-dir option if available) is sufficient.
2. Fix the related hardcoded path: clearGigetCache() in the skills installer rm-rf's ~/.cache/giget/gh/<owner>-<repo> unconditionally. If the cache moves (or a user sets XDG_CACHE_HOME themselves), the corrupted-archive recovery path clears the wrong directory and the retry loop can never self-heal.
3. Optionally: on EPERM from the cache path, surface a hint about macOS app-data protection rather than the raw errno, since the failure reads like a filesystem permissions bug and is not.

On macOS 26 this is a correctness issue, not a preference: any user who installs skills from a different terminal app than the one that first populated ~/.cache/giget hits a hard failure.

Related: #602 (skills update/provenance).