fix: stop raising findings no repair can clear

[SecretLUL]

Three findings survived their own repair: scan, repair, reboot, scan again — and there they were, unchanged. Each measured something the repair it offered could not touch.

Diagnosed against a real machine's last_scan.json, audit log and registry rather than from first principles.

wu_reboot_pending — a key the restart leaves behind

The check tested whether Component Based Servicing\RebootPending exists. Windows creates it while servicing and files the outstanding work underneath it; the restart consumes that work and empties the key, but leaves the key itself in place — permanently. On the machine this was found on it had been sitting there empty (0 subkeys, 0 values) while Auto Update\RebootRequired was absent: a restart that no restart could clear.

The CBS key now counts only while it still holds entries, and the two signals a boot really does clear are read alongside it — Auto Update\RebootRequired and PendingFileRenameOperations. pending_reboot_reason takes the three signals as data, so the verdict is testable without a registry to write into.

sys_clean_winsxs — a repair that could not move the number

The finding was raised on DISM's own "cleanup recommended" verdict. That verdict also weighs backups and disabled features, which only /ResetBase reclaims and which WinMedic deliberately never touches. StartComponentCleanup — the one repair offered here — removes superseded packages and nothing else. With 4.43 GB of backups and zero reclaimable packages the flag stayed Yes however often the repair ran, DISM answered "completed successfully" every time, and the audit log recorded a cleaned store.

• the finding now needs a reclaimable package to exist; a recommendation with nothing to reclaim goes to the scan log with the reason
• the repair reads the store back afterwards and reports what is left, instead of trusting an exit code that says the same thing either way
• both DISM calls pass /English. The output arrives in the console code page, so from_utf8_lossy had already cost the parser the store-size and cache lines on a German machine — visible in the finding's details as a missing "Explorer size"

sys_clean_setup_logs — the scan finding its own log

"13.2 MB, 2 files" were CBS.log, held open by TrustedInstaller since the log was created a month earlier, and dism.log — written by this module's own AnalyzeComponentStore call 34 seconds before the same scan measured it.

Both the measurement and the sweep now ask Windows for DELETE access first. That is exactly the question remove_file asks later, and with a fully permissive share mode the probe blocks nobody. What is counted is what can be removed; a rotated CbsPersist_*.log still is.

Checks

cargo fmt, cargo clippy --all-targets -D warnings and the full suite pass: 361 unit + 266 integration tests, 8 of them new for these three cases — an empty CBS key, a CBS key still holding work, a recommendation with nothing reclaimable, a cleanup that reclaimed nothing, and a log held open with FILE_SHARE_NONE that is neither counted nor reported as a failed deletion.

🤖 Generated with Claude Code