[Bug]: Cleanup — the "can be freed" figure stops counting at the first protected folder and follows junctions

[laurentiu021]

Problem

CleanupPreScanService sizes both temp folders with Directory.EnumerateFiles(path, "*", SearchOption.AllDirectories). Three defects follow from that one call, and the codebase already diagnosed and fixed all three elsewhere:

1. It aborts at the first unreadable subfolder. AllDirectories throws UnauthorizedAccessException out of MoveNext(), and the try sits outside the foreach — so the whole remaining walk for that path is abandoned and the headline reports whatever had been summed so far. Silently low, with no indication anything was skipped.
2. It follows reparse points. A junction inside %TEMP% is walked as if it were a real folder, so bytes living outside temp are counted as freeable. MeasureRecycleBin has the same call and the same exposure, where it is worse: deleting a junction puts a reparse point in the Recycle Bin, so the bin can size at tens of GB of live data.
3. It counts bytes the cleanup refuses to delete. 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 sweep skips SystemPaths.BundleExtractionRoot and SystemPaths.OwnExtractionDirectory. The pre-scan does not, so the headline promises space that Clean TEMP will correctly leave alone.

TuneUpService.EnumerateFilesSkippingReparsePoints exists precisely for this and solves all three: per-directory try/catch that continues, reparse-point skip at the root and every child, and exclusion subtrees.

Expected behavior

The pre-scan measures what the cleanup would actually delete, using the same walker and the same two exclusions. An unreadable subfolder is skipped, not treated as the end of the tree.

Evidence

• SysManager/SysManager/Services/CleanupPreScanService.cs — MeasureTemp and MeasureRecycleBin
• SysManager/SysManager/Services/TuneUpService.cs — EnumerateFilesSkippingReparsePoints
• ArchitectureTests.EveryTempTreeWalkerCall_PassesBothExtractionExclusions cannot see this: its walker-argument half is scoped to a hardcoded ["TuneUpService.cs", "DeepCleanupService.cs"], the same hardcoded-list weakness that let the third sweeper hide in CleanupViewModel for months.

Also in the same file: ICleanupPreScanService's doc offers "Unable to scan" as a possible TempLabel, which MeasureTemp cannot return — it catches per-path and always ends at Describe.

Affected tab

Cleanup

[laurentiu021]

Fixed in v1.76.10 via #2103.

Root cause. One call shape, three consequences: SearchOption.AllDirectories throws out of MoveNext() so the first protected subfolder ended the walk and the figure reported a partial sum; it follows reparse points, which is how a junction deleted into the Recycle Bin could add live data to that total; and it counted the extraction roots the temp sweep has skipped since #2094.

Fix. Both walks now use TuneUpService.EnumerateFilesSkippingReparsePoints with the same two exclusions the cleanup passes, so the estimate describes what pressing the button would actually free.

Also fixed here. The guard for that call shape read a hardcoded two-file list, so it could not see this caller at all — the same weakness that let a third temp sweeper hide in a view-model. It now finds callers by looking for them, and its declaration filter no longer mistakes CancellationToken.None at a call site for a parameter declaration (which would have skipped both new calls as declarations and checked nothing). Vacuity floor re-measured 5 → 7.

Verification. Three mutations, each red: a pre-scan call dropping its exclusions (named by file), a DeepCleanup call dropping its exclusions (so the older coverage is intact), and one call reverting to Directory.EnumerateFiles (caught by the population floor at 6 of 7).