fix: bound the Duplicate Files minimum-size box so it cannot invert its filter

[laurentiu021]

What a user sees

Open Duplicate Files, type a stray - (or a very large number) into "minimum size (KB)", and
Scan. Instead of finding only large duplicates it grinds through — and hashes — every file in the
folder. The one control meant to make the scan cheaper makes it maximally expensive, silently.

The defect

The scan keeps a file when it is at least the requested size:

if (fi.Length < minSizeBytes) continue;      // DuplicateFileService.Scan

and minSizeBytes was MinSizeKb * 1024, straight from a long-bound TextBox with no limits of its
own. Two typed values make that product negative:

• a leading minus — -1 → -1024;
• anything above long.MaxValue / 1024 — the multiply overflows and wraps negative.

Every real file length is ≥ 0 > negative, so the skip never fires: "only files above X" becomes
"every file in the folder". Nothing throws; the scan just does the opposite of what was asked, slowly.

The fix

The KB→bytes conversion moves into a pure, bounded helper:

internal const long MaxMinSizeKb = long.MaxValue / 1024;
internal static long MinBytesFor(long minSizeKb) => Math.Clamp(minSizeKb, 0, MaxMinSizeKb) * 1024;

so the threshold can never be negative by either route.

Deliberately not clamped in the setter. The box uses UpdateSourceTrigger=PropertyChanged, so
rewriting the value on every keystroke would fight the caret (type -, then a digit, and the field
would jump out from under you). The bound belongs where the value is used, not where it is typed —
the same reasoning the codebase already applies to live-updating inputs.

Found while triaging the pure-echo test MinSizeKb_CanBeChanged in batch 94, whose only "assertion"
set the property and read it back — it could never have caught this.

Verification

Red proof: 4 mutations, the touched source file restored byte-for-byte.

Mutation	Result
drop the clamp entirely (the shipped code)	negative and overflow tests both red
keep the lower bound only (Math.Max)	overflow test red, negative test green — isolates the upper bound
keep the upper bound only (Math.Min)	negative test red, overflow test green — isolates the lower bound
push MaxMinSizeKb one past the real limit	fails to compile (CS0220): the test asserts against the constant expression MaxMinSizeKb * 1024, which overflows at compile time — so the boundary itself cannot drift silently

That last one is a stronger guard than a runtime assertion: an off-by-one in the limit is rejected by
the compiler, not merely by a failing test. The three runtime tests are [Theory] rows covering
ordinary values (unchanged behaviour), negatives (-1, -5000, long.MinValue), and the exact
overflow boundary.

Other checks: all four projects build 0 errors / 0 warnings; dotnet format --verify-no-changes exit 0
on both; author headers intact; leak scan over all 32 terms gives 0 hits. fix: → patch release
(1.65.19).