Cover the remainder-only Mod kernels' rare Knuth paths

[LukaszRozmej]

Follow-up to #115, which landed the remainder-only Mod kernels. Those kernels' branches divide by how far the Knuth quotient estimate is off — the D3 correction, its second iteration, the saturating digit where the window's top limb equals the divisor's, and the add-back that fires on a borrow out of a limb no correction carried into.

I instrumented all 24 of those branches and ran the suite against the counters. It reaches 23 of 24, and several only incidentally: operands drawn at random almost never put the estimate near its bound. The one it never executes is the four-limb kernel's second D3 correction.

What is in it

One new test file, ModKernelTests.cs. Cases are constructed rather than sampled: x = q*y + r with q and r on the boundaries that drive those branches, swept over every (dividend limbs)x(divisor limbs) shape and every normalising shift, plus bit boundaries, the signed sign-combination arms, and single-limb moduli for MultiplyMod.

Two operand pairs found by search are pinned as literals for the uncovered branch. It needs a divisor whose normalised top limb sits just above 2^63 together with a dividend that fills limb 3, which a randomised search reaches about eight times in twenty million pairs — not something a generator should be relied on to rediscover.

Expected values come from BigInteger, never from limb arithmetic, so a shared mistake in the limb code cannot make a test agree with itself. Each pair is also checked against the remainder implied by Divide, which still goes through the full-quotient routine — a separate body of limb code, so the two agreeing is independent evidence, and a mismatch localises which of the two is wrong.

Validation

Branch coverage, from the instrumented build: 24 of 24, this file alone.

Injected faults, to check the tests bite rather than just pass — 8 of 10 caught:

Injected fault	Tests failed
add-back dropped, four-limb kernel	65
add-back dropped, three-limb kernel	66
add-back ignores the carry (borrow instead of borrow & (rcarry ^ 1))	3
saturation guard removed, three-limb	66
saturation guard removed, two-limb	68
second D3 correction removed, two-limb	66
digit skipped when it was needed, three-limb	3
digit skipped when it was needed, two-limb	7
second D3 correction removed, three-limb	0
second D3 correction removed, four-limb	0

The two survivors are not test escapes. Both kernels have an add-back, and Knuth's D3 test firing at all means the estimate was too large, so one correction plus the add-back reaches the same remainder — the second iteration is a performance refinement there, not a correctness requirement. Disabling it in the four-limb kernel moved two operations from the correction onto the add-back and changed no answer. The two-limb kernel has no add-back and its corrections must be exact, which is why removing its second correction fails 66 tests.

That is worth a look on its own: if the second correction is behaviourally dead in the three- and four-limb kernels, and it fires roughly eight times in twenty million operations, it may not be paying for the code and the branch. Not changed here — this PR only adds tests.

Separately, Mod/Divide/MultiplyMod/AddMod/SubtractMod/Int256.Mod were fuzzed against BigInteger over ~27M pairs with zero mismatches, in the default, no-AVX-512, no-AVX2 and no-intrinsics configurations — the last being the reciprocal path ARM64 takes. That fuzzing is what found the pinned pairs; it is not checked in.

• 587,786 tests pass (587,686 + 100).
• dotnet format whitespace --verify-no-changes clean, git diff --check clean.