fix: measure Cleanup's size estimates the way the cleanup actually works

[laurentiu021]

Closes #2098.

What was wrong

CleanupPreScanService sized both temp folders and the Recycle Bin with Directory.EnumerateFiles(path, "*", SearchOption.AllDirectories). Three defects from one call:

1. Silent under-reporting. AllDirectories throws UnauthorizedAccessException out of MoveNext(), and the catch has to sit outside the foreach — so the first folder Windows refuses ends the whole walk and the headline reports the partial sum, with nothing on screen to say so.
2. Follows junctions. Deleting a folder shortcut puts a reparse point in the Recycle Bin, so one deleted junction could add every file it pointed at — live data — to the "in Recycle Bin" total.
3. Counted what the sweep skips. Since [Bug]: Quick Cleanup - The temp sweep can delete the .NET extraction root of every running single-file app, and overcounts what it freed #2094 the temp cleanup excludes SystemPaths.BundleExtractionRoot and SystemPaths.OwnExtractionDirectory. The estimate did not, so it promised space Clean TEMP correctly refuses to free.

Both walks now go through TuneUpService.EnumerateFilesSkippingReparsePoints with the same two exclusions. That walker already carries tests for the directory-symlink, reparse-point-root and both-exclusion cases, so the pre-scan inherits proven behaviour rather than a second implementation.

The guard could not see this caller

EveryTempTreeWalkerCall_PassesBothExtractionExclusions checked walker arguments in a hardcoded ["TuneUpService.cs", "DeepCleanupService.cs"] list — the same weakness that let a third temp sweeper hide in CleanupViewModel for months. Two changes:

• It finds callers by looking. The file list is now the two sanctioned sweepers plus any file containing a SkippingReparsePoints( call. Only TuneUpService's walkers are reachable from outside, so that is exact.
• The declaration filter was matching call sites. It skipped any argument list containing CancellationToken — which CancellationToken.None contains, so both new calls would have been skipped as declarations and the guard would have read them and checked nothing. It now requires the type followed by a parameter name.

Vacuity floor re-measured 5 → 7 (five calls in the two sweepers, two in the pre-scan). Failure messages now name the file and the offending call.

Verification

Mutation proof, three cases, each restored byte-for-byte and re-hashed:

Mutation	Result
a CleanupPreScanService call drops both exclusions	RED — this walker call passes neither or only one extraction exclusion — CleanupPreScanService.cs: EnumerateFilesSkippingReparsePoints(...)
a DeepCleanupService call drops both exclusions	RED — names DeepCleanupService.cs: EnumerateFiles(p, ct), so the loose-name coverage is intact
one call reverts to Directory.EnumerateFiles(AllDirectories)	RED — only 6 walker calls were matched across 3 file(s), so the floor catches a regression to the unsafe API

Green at baseline and after restore. Regression sweep: ArchitectureTests 88 green (plus the harness-only author-header case for the throwaway runner), CleanupViewModelTests 104 green, TuneUpServiceTests 40 green. Builds 0 errors / 0 warnings, dotnet format --verify-no-changes clean on both projects, version consistency csproj 1.76.10 = CHANGELOG 1.76.10 = SECURITY 1.76.x.

Not covered by a test: the abort-on-protected-folder behaviour itself. Reproducing it needs a directory the test host cannot read, which on an elevated CI runner an admin bypasses anyway — that would be a machine-dependent test, not a deterministic one. The mechanical pin is mutation 3: the population floor reddens if any call site goes back to AllDirectories.

Docs

ICleanupPreScanService's contract offered "Unable to scan" as a possible temp label, which MeasureTemp cannot produce — it skips per path and always reaches Describe. Corrected to say what it really returns, including that an unreadable folder therefore reads as "Empty".