Compare a moving-exponent power against the right thing (#735)

[Rafael-SOWNet]

Fixes #735.

x ^ x and e ^ (x * ln(x)) are one function, so this is identically 1:

"x ^ x / e ^ (x * ln(x))".ToEntity().Limit("x", "+oo")   // 0

The library's own evaluator disagrees with its own limit: (50 ^ 50) / e ^ (50 * ln(50)) is exactly 1.

Cause

Gruntz's algorithm collects the subexpressions of the fastest comparability class into a set, then rewrites the expression by substituting each member by name. Mrv reads a power b ^ p whose exponent moves as exp(p * ln(b)) and puts that constructed node in the set -- but nothing rewrote the expression, so Rewrite's Substitute had nothing to find.

With GRUNTZ_DEBUG=1:

mrv(x ^ x / e ^ (ln(x) * x)) = {e ^ (x * ln(x)), e ^ (ln(x) * x)}
rewrite -> = x ^ x / (e ^ 0 * (1 / %1) ^ 1)   logw=-ln(x) * x
leadterm(x ^ x / e ^ (ln(x) * x)) = (x ^ x, 1/1)

The same exponential is in the set twice -- once as the constructed e ^ (x * ln(x)), once as the denominator's own e ^ (ln(x) * x), the same product with its factors the other way round, because simplification had sorted the copy already in the expression and the constructed one was never sorted. Only the second is found. x ^ x goes into the series unchanged, its leading exponent reads as +1, and w ^ positive tends to zero.

Fix

Fixed where the reading is made rather than where it is used: every power whose exponent moves is written as an exponential once, at the entry, so Mrv's reading of a node and the node itself are the same syntax by construction. That also collapses the duplicate, since the two spellings now normalise together.

This assumes the base is positive, which is what Mrv's own reading of the same node already assumed -- the algorithm is scoped to the exp-log functions, and a moving exponent over a base that changes sign is outside that class either way. Checked: (-2) ^ x still answers NaN and (-1) ^ x / x is still declined, both as before.

A backstop alongside it, because the failure was silent rather than loud: if any member is still in the expression after the substitution, decline. A member left in the series is read as part of a coefficient and the conclusion is then drawn from a leading term that is not the leading term.

Measured

	before	after
x ^ x / e ^ (x * ln(x)) (is 1)	0	1
e ^ (x * ln(x)) / x ^ x (is 1)	no answer in 20 s	1, in 226 ms
x ^ x / e ^ (x * ln(x) - x) (is e ^ x)	0	+oo
x ^ x / e ^ (x * ln(x) - ln(x)) (is x)	0	+oo
x ^ (2 * x) / e ^ (2 * x * ln(x)) (is 1)	0	1
(x ^ 2) ^ x / e ^ (2 * x * ln(x)) (is 1)	0	1

x ^ x / e ^ x and x ^ x / 2 ^ x were right before and are unchanged: this needs the two sides to be in the same comparability class, which is exactly when Gruntz's algorithm is the rule that answers rather than an earlier one.

Full suite 4904 passed / 0 failed with this change alone -- the 15 above master's 4889 are the ones added here -- F# 130/130, corpus 112/117 with 0 wrong, 0 error, 0 timeout. All pre-existing GruntzTest cases pass unchanged.

🤖 Generated with Claude Code

[Rafael-SOWNet]

Note on the Test (macos-latest) failure visible in this PR's history: it was a runner flake, not a regression. Re-running the identical commit passes on all three platforms.

The failing assertion was VanishingTimesDivergingTest's wall-clock guard --

Assert.True(task.Wait(TimeSpan.FromSeconds(30)), "the limit did not terminate");

-- so it was a timeout, not a wrong answer. Three separate grounds for calling it a flake:

1. Re-run of the same commit is green on macOS, ubuntu and windows.

2. No measurable timing effect. Per-test durations, master against this branch:

   case	master	this branch
   sqrt(x) * ln(x) / (2 + x)	899 / 849 ms	861 / 855 / 852 ms
   x * ln(x) / (1 + x)	1 s	1 s
   x * ln(x) / cos(x)	1 s	1 s

   About 1 s against a 30 s budget.

3. The change cannot reach those expressions. AsExponentials rewrites only a power whose exponent contains the variable, and none of the three has one -- 1/x and sqrt(x) both have constant exponents -- so it is a no-op on all of them. The other half of the change makes Rewrite decline earlier, which cannot cost time. Confirmed by tracing: Gruntz declines x * ln(x) / cos(x) immediately at mrv(...) = null, because of the cosine, exactly as before.

Worth recording separately, since it is not this PR's doing: that macOS job took 13 m 22 s against about 3.5 min locally, and the guarded limit runs in parallel with the other ~4900 tests. A 30 s wall-clock budget on a 1 s operation under that much contention is inherently fragile. The budget exists to catch a hang rather than to measure duration, so it could be raised substantially without weakening what it checks -- but that is a change to a test unrelated to this one, so I have left it alone rather than bundle it here.