Bound a gcd's intermediates separately from its inputs (#920)

[Rafael-SOWNet]

Closes #920.

PolynomialGcd.Gcd declined on inputs well inside every documented limit, because an intermediate of the subresultant remainder sequence went past MultivariatePolynomial.MaxTerms while neither input nor answer came close:

left   (b + c + 1) * (a + b) * (a + b + c + d)                 19 terms
right  (a^2 + b*c + d) * (a + b + c + d) * (a + b + c + d)     29 terms
gcd    a + b + c + d                                            4 terms   was declined

A multivariate pseudo-remainder multiplies through by a leading coefficient that is itself a polynomial. The subresultant divisions bound how large the coefficients get — which is what the class remark is about, and it holds — but nothing bounds the monomial count, and three steps in, a 25-term lead times a 159-term remainder passes 512.

Why not just raise MaxTerms

#920 offers that as the one-line option and asks for a measurement rather than a guess. The measurement rules it out. At MaxTerms = 2048, three documented refusals become answers:

• TermCountsPastTheCeilingAreRefused — whose subject is a direct product of two 495-term inputs
• RefusedRatherThanAnsweredWrongly — whose input has 1001 terms and is meant to be stopped at the door
• the Multivariate GCD declines when an intermediate of the remainder sequence exceeds the term ceiling #920 case itself

Only the third is the bug. The bound on what may be asked was never too small; what was too small was the bound on what may be passed through on the way to an answer that is itself small.

The shape

MaxIntermediateTerms = 4096 is a second constant, threaded as an optional argument through Multiply, Power and DivideExact, and passed only by the gcd's remainder sequence. Everything reached any other way keeps MaxTerms by default, so the entry bound protecting the hot path is untouched and all three refusals above still refuse.

3000 drawn triples   7 declined  ->  0 declined
the pair above       declined    ->  a + b + c + d, checked as a greatest common divisor

The sweep now asserts the count is zero rather than at most seven, so a refusal coming back fails there instead of passing quietly under a ceiling. The pinned refusal test is rewritten to assert the answer deliberately, as its own remark asked for.

Performance

TryCancel runs on every quotient the simplifier builds, so simpsweep is the hot path.

ceiling	run
4096	3m26.8s
4096	3m40.7s
512 (old behaviour)	3m45.3s

The spread between repeats of the same setting is as large as the gap between the settings. This supports no regression; it does not support a speedup, and I am not claiming one. The gcd test class is unchanged at 1 s.

Verification

• 6944 C# tests, 130 F# tests — 0 failures
• propcheck 1340 checks, 0 failures
• simpsweep 10463/10463 agree, 0 disagreements, 0 timeouts
• rootcheck 596/596 clean, 0 incomplete, 0 unsound
• casbench 117/119, 0 wrong, 0 error, 0 timeout

🤖 Generated with Claude Code