macOS disk looks full: Chrome code_sign_clone dir shows hundreds of GB but is mostly APFS clones; Remotion setBrowserExecutable multiplies it

On macOS, du on /private/var/folders/<id>/X/com.google.Chrome.code_sign_clone reported 490 GB on a 494 GB disk (328 subdirs, ~1.5 GB each). Chrome creates an APFS clone of its own bundle on every launch and leaves it behind when the process is killed instead of quit. Clones share blocks, so real usage was only ~1.5 GB per distinct Chrome version left behind (4 versions = ~6 GB), verified with fcntl F_LOG2PHYS: same version -> same physical offset. Sanity check: if du of the volume exceeds the volume size, you are counting clones. Root cause of 285 clones in 3 days was a Remotion project with Config.setBrowserExecutable("/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"); every remotion render/still (and headless --screenshot runs) spawned system Chrome. Fix: drop setBrowserExecutable so Remotion uses its own chrome-headless-shell, quit Chrome, delete the stale clone dirs. Separately, the real gap between du and diskutil used space came from TCC-protected dirs (Messages, Mail, Safari, Photos) and root-only dirs that an unprivileged sandboxed du silently skips (Operation not permitted), plus /System/Library/AssetsV2 (iOS simulator runtime 8.5 GB, staged macOS update 2.9 GB).