Let the logarithm's domain follow the reading (#721, #890)

[Rafael-SOWNet]

Closes the cheap half of #721, and #890's contradiction with it.

Arcsinf, Arccosf, Arcsecantf and Arccosecantf each state one condition over the reals and another over the complex plane, and pick between them by the reading. Logf stated the real one as though it were the only one. So the library gave an expression a value and declared it undefined at the same time — which is exactly what #890 reported:

log(-3, -3)                      1
log(-3, -3).DomainCondition      False

What changes

Over the complex plane log_b(a) is ln(a) / ln(b), which asks only that both logarithms exist and that the denominator is not zero: no complex number has 0 as its exponential, so a and b must be nonzero, and ln(b) = 0 is b = 1.

	was	is
log(-3, -3).DomainCondition	False	True
ln(x).DomainCondition	x > 0	not x = 0
"log(x, x)".Simplify()	1 provided x > 0	1 provided not x = 0 and not x = 1
"x ^ n".Differentiate("x").Simplify()	x ^ n * n / x provided x > 0	x ^ n * n / x provided not x = 0

The real condition is still there and still reachable. expr.WithCodomain(Domain.Real) gives x > 0 and not x = 1 for log(x, x) exactly as before. What changed is which of the two is the default, and the default is now the same complex reading the evaluator has always used.

The rewrite was wrong in both directions at once

log_b(b) -> 1 asserted provided x > 0 — the real condition, written out inside the rule rather than read from the node. It withdrew an answer that exists and kept one that does not:

at x = -3     NaN  ->  1      (the logarithm is 1)
at x =  1     1    ->  NaN    (the logarithm is NaN)

Only the first of those is a boundcheck finding; the second was not reported by anything and turned up on the way.

The zero cases are stated, not read off evaluation

Evaluation returns the extended-real -oo for ln(0), so reading the condition off it would call ln(x) defined everywhere. -oo is not a complex number, and taking it for one loses a condition that is needed downstream: ln(x) * 0 is 0 wherever ln(x) has a value and NaN at x = 0, since -oo * 0 is indeterminate. That is why d/dx x^n keeps not x = 0 rather than losing its condition altogether — and it drops x > 0, which had been costing the answer at every negative x:

n = 3, x = -2.5      NaN  ->  75/4        and 3x^2 at -2.5 is 75/4

Measured

• boundcheck: 2 disagreements -> 1, both runs on the same harness build (master re-measured rather than read off the committed report, which was generated by an older one: 945 comparisons then, 966 now).
• The survivor is ln(x) + ln(x+1) -> ln(x*(1+x)), which needs an assumption travelling with the variable — Unify Codomain with a "provided ... in RR" condition #721's expensive half — and is untouched here.
• 6504 C# tests pass (6487 before, plus 16 new cases and one expectation corrected), 130 F# tests pass.
• The corrected expectation is DerivativeGapsTest.SymbolicExponentsAreUnaffected, whose provided x > 0 was the stale real-domain claim. Its stated purpose — that a genuinely symbolic exponent still takes the logarithmic rule, condition and all — still holds.

Every changed answer is in BREAKING-CHANGES.md under Unreleased — since 2.1.0, with the value before and after, measured on a build of each.

What this does not do

The other half of #721 — assumptions attached to variables, Symbol('x', positive=True)-style and three-valued — is untouched. That is what would buy the ln(a) + ln(b) guard and the two limits #902 withdrew, and it is #746's tier 1 rather than a rule fix.