Drop un-cleanable scan items before they reach the UI (1.5.1)

[iliyami]

Summary

Stops showing items the current process can't trash. After 1.5.0 the completion screen still listed 10 stubborn errors on a real-world clean — all of them paths nothing on this machine could ever clean:

• Root-owned children of writable parents — /Library/Caches/com.apple.InferenceProviderService/, /Library/Logs/PaloAltoNetworks/GlobalProtect/*.log, /private/var/log/com.apple.xpc.launchd/launchd.log. Parent dirs are 0755 root:wheel, so unlink from inside returns EACCES.
• Data-vaulted Apple caches in the user's home — ~/Library/Caches/com.apple.containermanagerd/, …ap.adprivacyd/, …Safari.SafeBrowsing/. macOS marks these UF_DATAVAULT; the kernel rejects writes regardless of FDA, ownership, or root. EPERM at the syscall.

Both categories surface as access(W_OK) denials at the syscall layer, so a single probe in MacCleanKit/CleanFilter covers both. ScanCoordinator.scanModules applies it once to every module's results — the only choke point that touches all 13 modules.

What changed

• Sources/MacCleanKit/CleanFilter.swift (new, 35 LOC) — isCleanableByCurrentProcess(URL) -> Bool. Checks parent dir writability; if the item is a directory, also checks self writability.
• Sources/MacClean/Core/Scanner/ScanCoordinator.swift — single insertion point, filters every module's results before they become ModuleScanResult.
• Tests/MacCleanKitTests/CleanFilterTests.swift (new) — 6 spec tests: cleanable file in writable dir, cleanable dir, non-existent path, unwritable parent, unwritable self, files-inside-unwritable-parent.
• Tests/MacCleanTests/ScanCoordinatorTests.swift + SmartScanE2ETests.swift — two pre-existing tests used non-existent fake URLs (/tmp/f0, /tmp/a.cache); the filter correctly dropped them, breaking aggregation assertions. Updated to materialize real files in per-test temp dirs.
• VERSION + MCConstants.appVersion → 1.5.1.

Why a blanket filter (not module-scoped)

Optimization / Maintenance / Updater items aren't trashed via FileManager, so in theory the filter could over-reach. In practice their items don't live under root-owned dirs (launch agents the user can disable live in ~/Library/LaunchAgents/, login items in ~/Library/Application Support/). And if some did, surfacing them in the UI without an actionable cleanup path was already misleading UX. Re-evaluate if we ever build the XPC helper for elevated cleanup.

Real-system probe (pre-implementation)

Verified access(W_OK) semantics on the actual user-reported error paths before writing code:

✓ /Library/Caches → WRITABLE
✗ /Library/Caches/com.apple.InferenceProviderService → DENIED(errno=13)
✗ /private/var/log/com.apple.xpc.launchd/launchd.log → DENIED(errno=13)
✓ /Users/iliya/Library/Caches → WRITABLE
✗ /Users/iliya/Library/Caches/com.apple.ap.adprivacyd → DENIED(errno=1)
✗ /Users/iliya/Library/Caches/com.apple.containermanagerd → DENIED(errno=1)
✗ /Users/iliya/Library/Caches/com.apple.Safari.SafeBrowsing → DENIED(errno=1)

Both errno=13 (EACCES, POSIX) and errno=1 (EPERM, data-vault) surface as access != 0. One probe, both cases.

Test plan

• swift test — 387 tests, 4 skipped (existing XPC-skipped), 0 failures
• swift build — clean
• bash scripts/check-version-sync.sh — VERSION ↔ MCConstants synced at 1.5.1
• Local install of the 1.5.1 DMG: run a System Junk clean, confirm the completion screen shows 0 errors (or only "real" errors, not the 10 prior fixtures)
• CI green, Release green, brew cask synced after merge