Xcode.xip No Space Left On Device On Linux tmpfs

When `Xcode.xip` extraction fails around the SDK/framework write step but the main disk still has free space, check the temp filesystem before deleting project files.

Why it happens

Large Xcode archives can expand through `TMPDIR`, `/tmp`, or another temporary extraction path. On many Linux desktops and CI images that path may be a small tmpfs backed by RAM or a small mount, so extraction reports `No space left on device` even when `/home` has tens of gigabytes free.

Read-only evidence block

printf "\n## main filesystem\n"
df -h "$HOME" .
df -i "$HOME" .

printf "\n## temp filesystem\n"
printf "TMPDIR=%s\n" "${TMPDIR:-/tmp}"
df -h "${TMPDIR:-/tmp}" /tmp
df -i "${TMPDIR:-/tmp}" /tmp
mount | grep -E " /tmp |tmpfs|${TMPDIR:-/tmp}" || true

printf "\n## xip and target\n"
du -sh ./Xcode*.xip 2>/dev/null || true
du -sh ./Xcode.app 2>/dev/null || true

Safe first workaround

Move the extraction temp path to a real disk location with enough free bytes and inodes. Keep the original `.xip` and partial `Xcode.app` until you know whether the retry completed.

mkdir -p "$HOME/.xcode-xip-tmp"
df -h "$HOME/.xcode-xip-tmp"
TMPDIR="$HOME/.xcode-xip-tmp" xtool setup

Product-side acceptance criteria

• Before extraction, compare required expansion headroom against the actual temp mount, not only the target directory.
• If `TMPDIR` is tmpfs or has low free space, fail early with the temp path and a suggested disk-backed override.
• Clean partial extraction directories only after the failed target is clearly identified.
• Do not tell users to delete Xcode archives, app support folders, or unrelated project state when only tmpfs is full.