Read arccotan's range off arccotan rather than off a textbook (#887)

[Rafael-SOWNet]

Fixes two wrong answers, one of which is a correction to 2.0.0 — the guard I added in #885 used
the wrong interval.

Closes #887's first two sections.

One fact, two consequences

This library's arccotan is arctan(1/x) extended by arccotan(0) = pi/2, so its range is
(-pi/2, pi/2] and not the (0, pi) that many textbooks use. Measured: arccotan(1) is pi/4,
arccotan(-1) is -pi/4, arccotan(0) is pi/2.

	was	is
arctan(-3) + arccotan(-3)	pi/2	-1/2 * pi — the value
arctan(3) + arccotan(3)	pi/2	unchanged
arctan(x) + arccotan(x), symbolic	pi/2	left as written
arccotan(cotan(2))	2	-1.1416... — the value, 2 - pi
arccotan(cotan(-1/2))	left as written	-1/2

The sum. pi/2 for a non-negative real argument, -pi/2 for a negative one. pi/2 * sgn(x) is
the closed form and is wrong at exactly one point — at x = 0 the sum is pi/2 while sgn(0) is
0 — so the sign is decided where it can be read and the sum is left alone otherwise. A Piecewise
would be total, and is not used because Compile throws UncompilableNodeException on one, so
answering that way would stop expressions compiling that compile today.

The neighbouring arcsin(x) + arccos(x) -> pi/2 is untouched and needs no assumption, since
arccos(x) is pi/2 - arcsin(x) by definition over the whole plane. The block had a sound half
and an unsound half written as though they were symmetric — the same shape as #884, four lines
apart, which is worth noting as a thing to look for.

The composition. #885 guarded arccotan(cotan(x)) with [0, pi], which admitted (pi/2, pi)
where the rewrite is false and refused (-pi/2, 0) where it is true. Now (-pi/2, pi/2] without
zero — zero excluded because cotan has no value there, so the composition has none either and
rewriting to x would invent one. The other three intervals from #885 check out against the same
measurements: arcsin [-pi/2, pi/2], arccos [0, pi] (arccos(-1) is pi), arctan
(-pi/2, pi/2).

How it was found, which is the part worth reading

By work/boundcheck, written for exactly this class after #884 showed that four rules had been wrong
since 2020 with every harness green. It composes every unary function node with every other — found
by reflection, so a node added later is covered without anyone remembering — and compares each
simplification against the original at points chosen to sit where an assumption fails, rather than
at sampled points. Both undefined counts as agreement.

It found an error in my own merged fix within minutes of existing. That is the argument for building
it: simpsweep samples real points and cannot see a rule that is wrong off the real line, and its
grammar never nests a function inside its own inverse, so this shape was outside its space entirely.

First run: 366 shapes, 936 comparisons, 5 disagreements. Now 4, and every one of those is filed —
two are #884's logarithm half, log(x, x) -> 1 provided x > 0 has a condition too strong (at
x = -3 the value is 1 and the simplification is undefined) and is recorded on #887, and
ln(x) + ln(x+1) is the known domain-widening gathering.

Tests that moved

Three asserted pi/2 for a symbolic argument, so all three were pinning the wrong answer. Each
now uses numbers and covers both signs.

SortSimplifyTest's arctan(x2) + arccot(x*x) case is the interesting one: it sorted and collected
its whole nine-term sum only because the collapse to pi/2 shortened it and made the sorted
candidate win on complexity. With the collapse gone the sum stays as written. x^2 is not a known
non-negative for a symbolic x — at x = i it is -1 — so declining is correct, and the sibling
arcsin/arccos case still collapses and still sorts. The comment says so, so nobody reads it as
sorting having broken.

New regression cases assert the value and take the argument as a number before Simplify
runs, because that is what the guard reads: my first attempt simplified the symbolic form and
substituted afterwards, which passes whatever the interval says.

Measured on this branch, .NET 10

C# tests	6296 passed, 0 failed, 14 skipped
F# tests	130 passed, 0 failed
casbench	117/119, 0 wrong, 0 error, 0 timeout
propcheck	1340 checks, 0 failures
rootcheck	596/596 clean
simpsweep	10463/10463 agree, 0 disagree
boundcheck	5 disagreements → 4, all four filed

One thing found while measuring, not fixed here

dotnet test -c release (lowercase) cannot build AngouriMath.FSharp from clean on a
case-sensitive filesystem. The fsproj hardcodes
<DocumentationFile>bin\Release\netstandard2.0\AngouriMath.FSharp.XML</DocumentationFile> under a
condition that MSBuild compares case-insensitively, so with -c release the condition matches while
$(OutputPath) becomes bin/release/ — and the compiler fails with
FS0193: Could not find a part of the path ... bin/Release/.... -c Release works, and so does
-c release once a capitalised build has created the directory, which is why it has not been
noticed. Filed separately; the fix is <GenerateDocumentationFile>true</GenerateDocumentationFile>
instead of a hardcoded path.

[Happypig375]

Should we fix the range to be (0, pi) instead?