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

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).

Start in the skills installer at clearGigetCache() and trace the giget download call to see how its cache directory is selected. Reproduce the reported cmd skills add command, then verify that downloads use ~/.commandcode/cache/giget and that corrupted-archive cleanup targets the same location, including when XDG_CACHE_HOME is set.