Add boundary tests for MaxDeleteGuard trigger threshold

[in-jun]

The existing suite never pinned the exact minDeletionsToTrigger boundary: the closest case (5 of 10 = 50%) is filtered out by the fraction check rather than the trigger comparison, so a regression flipping < to <= (or back) would go unnoticed.

• Add a test asserting that exactly minDeletionsToTrigger deletions above the fraction threshold (5 of 6 = 83%) aborts, and a companion test that one below the count (4 of 5 = 80%) is allowed — together they pin both sides of the strict < boundary.

Fixes #96

[in-jun]

Verified against MaxDeleteGuard.evaluate (the deletions < minDeletionsToTrigger short-circuit at line 30). The two new tests pin exactly the gap issue #96 called out:

• exactly the trigger count over threshold aborts — 5 of 6 (83%) with minDeletionsToTrigger = 5. Flipping < to <= makes 5 <= 5 short-circuit to null, so the abort disappears and this test fails. The deletions/total/side assertions match the Abort fields precisely.
• one below the trigger count is allowed even over threshold — 4 of 5 (80%) stays Ok, pinning the allowed side of the boundary. The pre-existing 5-of-10 case only ever exercised the fraction check (50% is filtered by fraction <= threshold regardless of the trigger comparison), which is exactly why it couldn't catch this.

Ran the class locally on JDK 21 — all 6 tests pass. Additive and test-only, no production changes. Comments are accurate. Looks good.