Cancel an inverse trigonometric function only on its own branch (#884)

[Rafael-SOWNet]

Fixes three wrong answers. Simplify cancelled an inverse trigonometric function against its
own function unconditionally, and that identity holds only on the interval the inverse answers
in.

Closes #884's trigonometric half. The logarithm half of that issue is deliberately not here;
see below.

What was wrong

Patterns.Trigonometry.cs had this, with a comment stating an identity that is false:

// arcfunc(func(x)) = x
Arcsinf(Sinf(var any1)) => any1,
Arccosf(Cosf(var any1)) => any1,
Arctanf(Tanf(var any1)) => any1,
Arccotanf(Cotanf(var any1)) => any1,

Outside the principal interval the composition folds back into it, so:

	Simplify said	the value is
arcsin(sin(x)) at x = 3	3	0.14159...	pi - 3
arctan(tan(x)) at x = 2	2	-1.14159...	2 - pi
arccos(cos(x)) at x = 4	4	2.28318...	2*pi - 4

Simplify claims its output is another way of writing the same value, so these are the worst
category in AGENTS.md — not a missing answer but a wrong one. The rules date from 6b662539
(2020-10-11) and are present in v1.4.0.

The fix

They fire only where the argument is a real number that can be placed inside the interval —
[-pi/2, pi/2] for arcsin, [0, pi] for arccos, and the corresponding open intervals
for arctan and arccotan, since tan and cotan have no value at the endpoints and neither
does the composition.

The exact answer that made the rule worth having is kept: arcsin(sin(1/2)) is still 1/2,
not a decimal. A symbolic argument is left as written, which is what SymPy
(asin(sin(x)) stays) and Mathematica both answer, and declining is a legitimate answer where
returning x is not.

A condition was deliberately not attached. x provided x >= -pi/2 and x <= pi/2 would say
the expression is undefined outside the interval, and it is not — it has a different value.
That replaces a wrong value with a wrong domain.

The other direction is untouched, and there is now a test holding it there:
sin(arcsin(z)), cos(arccos(z)), tan(arctan(z)), cotan(arccotan(z)) compose the right
inverse and are z wherever the inner function is defined, with no assumption needed. The
original block had one sound half and one unsound half written as though they were symmetric,
which is how it survived.

The interval test doubles the argument and compares against pi rather than halving pi,
because addition of two EDecimals is exact and division is not. It is still only as good as
the working precision, and an argument that close to an endpoint is treated as outside — the
direction that declines to rewrite.

CircleTest.Test8 was pinning the wrong answer

It asserted arccotan(cotan(3x)) == 3x. arccotan answers in (0, pi), so at x = 2 the
expression is about 2.86 against 6. It now asserts the expression is left alone. That is the
"the test was pinning a fudge" case from the contributing notes, and it is called out in the
commit message and in BREAKING-CHANGES.md.

Measured on this branch, .NET 10

C# tests	6270 passed, 0 failed, 14 skipped
F# tests	130 passed, 0 failed
casbench	117/119 with an elementary answer, 0 wrong, 0 error, 0 timeout — unchanged
rootcheck	596/596 clean, 0 incomplete, 0 unsound
propcheck	1340 checks, 0 failures
simpsweep	10463/10463 agree, 0 disagree, 0 timed out

The eight new regression cases assert the value at a point outside the interval rather than
a printed form, since the value is what the bug was. Five more pin that the cancellation still
happens, and exactly, inside the interval.

Why the logarithm half of #884 is not here

log_b(a^c) -> c * log_b(a) (Patterns.Power.cs:158) is unsound the same way: ln(e^y)
simplifies to y, and at y = 3*pi*i the left side is pi*i while y is 3*pi*i. I wrote
the guard and measured it — it costs two limits their answers:

lim x->+oo x^x / e^(x*ln(x) - ln(x))     is +oo,  becomes unevaluated
lim x->+oo (x^2)^x / e^(2*x*ln(x))       is 1,    becomes unevaluated

Unevaluated is honest rather than wrong, so that is a coverage loss and not a new defect — but
it is a loss for two limits that work today, and it is not the real choice. This is #802
exactly: the limit machinery needs the identity only in a neighbourhood of the destination,
where it is checkable because the base is eventually positive, and Limits/Transformations.cs
already carries the a^n/b^n case behind IsEventuallyPositive for that reason. The logarithm
wants the same treatment in the same place, and LogarithmExpanded — which already splits
ln(b^e) for the limit machinery with no positivity check at all — is both its natural home
and something to tighten in the same change.

That is written up with the measurements in
#884 so it is
a defined piece of work rather than a note in a diff, and it is kept out of here because this
change fixes three wrong answers and does not touch the logarithm.

One aside worth having

Writing the principal-branch test ran straight into #873:
Assert.Equal("1/2".ToEntity(), "arcsin(sin(1/2))".ToEntity().Simplify()) fails, because 1/2
parses as a Divf while the answer is a Rational and Entity equality is structural. The
test simplifies both sides to get round it, and says so. A second concrete cost of 1/2 having
no node of its own.