Deletion guard does not pause on a large mass deletion (87% of folder) #204

Observation

During end-to-end validation, a folder with 300 synchronized flat files had 260 of them removed locally (87%, well above the account's thresholds of count=10 / percent=20%). Expected: the deletion guard pauses sync and raises DeleteReview before the engine propagates the deletions to the server. Observed: the folder returned to Sincronizado (IdleOk) and the deletions were processed; the guard never paused.

In an earlier smaller test (12 of 20 removed, i.e. 60%, also above percent=20%) the guard did pause and raise DeleteReview.

Why it matters

The guard exists precisely to stop an accidental mass deletion from reaching the server. A 260-file deletion is the worst case for that, and it did not pause. This is a real reliability gap in the safety feature, independent of the proactive notification work (#203).

Repro context

• Account hub.domatix.com, delete_guard.enabled=true, count_threshold=10, percent_threshold=20.
• A test folder ~/temp/nextsync-test synced 300 flat files to a remote path, then 260 were removed locally in one shot.
• The removal was detected (folder re-synced), but the guard did not flag it. The same folder path had been used for a previous (12-file) test, so the engine may have carried a baseline/journal that changed the guard's view — worth investigating.

What to investigate

• How the guard derives "previously present" paths (journal/baseline) and why an 87% removal did not exceed the effective threshold.
• Whether the engine's async reconciliation runs before the guard scans (race), letting deletions propagate unfiltered.
• Whether the previous test run left a stale journal/baseline that skewed the comparison.

Acceptance

• A delete of a high fraction (> count and > percent threshold) of a folder's files pauses sync and surfaces DeleteReview before the engine propagates, consistently (not just for the 12-file case).