AppCleaner: Make deleted item count match the scanned count

[d4rken]

What changed

After cleaning with AppCleaner, the result could show far fewer "items deleted" than the scan reported as "found" — e.g. a scan finding 4876 items / 2.5 GB would show 80 items deleted / 2.6 GB freed. The freed space was correct and nothing was skipped, but the item counts looked wildly inconsistent and read like a bug.

The number now reflects the same thing the scan counted, so the "found" and "deleted" counts line up.

Technical Context

• Root cause: the scan counts every expendable file individually (sum of AppJunk.itemCount), but the post-deletion result reported affectedPaths.size. On non-root devices, caches are cleared by the accessibility service tapping "Clear cache" per app — that whole-folder clear contributes only its ≤2 synthetic theoreticalPaths to affectedPaths, so hundreds of scanned files collapse to ~1–2 counted paths. Two incompatible counting scales, not data loss.
• Fix: derive affectedCount from the before/after scan totals (snapshot.totalCount - internalData.totalCount) instead of affectedPaths.size. This reuses the exact counting the scan already does, so it can't drift from the "found" rules, and it counts ACS cache clears at scan scale. Chosen over a hand-rolled per-item counter (which would have to re-derive the accessible/inaccessible/public-cache rules and risk double-counting).
• affectedPaths is left unchanged, so the stats path-record subsystem is unaffected. Side effect: the lifetime "items processed" stat stops undercounting ACS deletions, and the stats detail header now shows the true item count above the (inherently shorter) recordable-path list — accepted, since inaccessible cache files have no enumerable paths.
• Propagated affectedCount through the OneClick and Scheduler success wrappers so background/one-tap runs report consistently too.
• Review guidance: the count is a before/after snapshot diff taken under toolLock; coerceAtLeast(0) guards the (not-expected) negative case. Tests cover the ACS-cleared count, a failed clear (no overcount), includeInaccessible=false, and OneClick/Scheduler propagation.