Keep the domain of a substituted variable in a change of variables

[s-celles]

Fixes #145.

∫ sin(sqrt(1+x))/sqrt(1+x) dx comes back unevaluated. It is entry 15 of the difficult
baseline, and it is the single regression that fails the difficult gate on every currently
open pull request.

What happens

With verbose tracing, rule 4_1_12_81 changes variables to u = (1 + x)^(1//2):

┌-------Applied rule 4_1_12_81 (change of variables):
└-------with result: ∫(sin(u)*u) / ((u^2)^(1//2)) du where u = (1 + x)^(1//2)
No rule found for ∫((sin(x)*x) / ((x^2)^(1//2)), x)
                → ∫((sin(x)*x) / abs(x), x)
No rule found for ∫((sin(x)*x) / abs(x), x)

u is a principal square root, so sqrt(u^2) is u and the integrand is just sin(u).
Nothing records that u >= 0: int_and_subst receives to, the expression the new variable
stands for, and discards it. simplify then turns (u^2)^(1//2) into abs(u), which no rule
matches.

The upstream rule producing that abs is correct — it was added in
JuliaSymbolics/SymbolicUtils.jl#1077 to fix the unsound fold of sqrt(x^2) to x
(JuliaSymbolics/SymbolicUtils.jl#1045). The gap is on this side.

The change

int_and_subst now uses to: when the new variable stands for a principal even root, it
rewrites abs(u), sqrt(u^2) and (u^2)^(1//2) to u before integrating.

integrate(sin(sqrt(1 + x)) / sqrt(1 + x), x)
# before: ∫(sin(sqrt(1 + x)) / sqrt(1 + x), x)
# after:  -2cos((1 + x)^(1//2))

nonnegative_substitution is deliberately narrow: sqrt(...), or a power whose exponent is a
positive rational with even denominator. An odd root such as (1 + x)^(1//3) can be negative,
so it is not claimed nonnegative and its abs is kept. A test pins that in both directions,
because getting it wrong would silently drop an absolute value that carries meaning.

Tests

test/methods/rule_based/test_substitution_domain.jl, in the easy group: the two helpers
(including the odd-root and non-root cases that must stay untouched, and that only the named
variable is rewritten), the integral of #145 against its expected antiderivative, and two
neighbouring integrands from the same rule family to catch a rewrite that is too eager.
19 passed.

TEST_GROUP=easy: 221 passed, 1 broken (pre-existing), exit 0. Julia 1.13.0, SymbolicUtils
4.48.0, Symbolics 7.41.1, Nemo 0.56.1, AbstractAlgebra 0.50.2.

TEST_GROUP=difficult could not be completed on the machine I am on, so the CI gate is the
check to read here. Since entry 15 is the only regression that gate currently reports, this
should turn difficult green — on this branch and, once merged, on the other open pull
requests. Note that the same runs also report five Risch improvements ([3], [26], [27],
[49], [55]) which show up on unrelated pull requests too: they come from dependency drift and
would be worth a separate baseline refresh.

Assisted by: AI

How this sits with the other open pull requests

Seven of mine are open at the moment, and every one of them shows the same two red groups for
reasons none of them introduced. Two of the seven remove those causes, and they are
complementary — each one turns green what the other leaves red:

• Allow SymbolicIntegrationMaxima 0.3 in the qa test environment #146 (one line) fixes the qa jobs of the SymbolicIntegrationMaxima workflow, which
  cannot resolve since the 0.3.0 release of that sub-package. It has failed on main since
  then, so every pull request that merges current main inherits it.
• this PR fixes the single difficult regression, entry 15, which is the only thing
  failing that gate anywhere.
• Refresh the Risch baseline for five entries the engine now verifies #148 refreshes five Risch baseline entries the engine now verifies. It does not gate
  anything; it just stops the harness asking for it on every run.

A merge order that avoids re-running red CI for nothing:

1. Allow SymbolicIntegrationMaxima 0.3 in the qa test environment #146 and Refresh the Risch baseline for five entries the engine now verifies #148 — one line and five digits respectively, no behaviour change.
2. this PR (Keep the domain of a substituted variable in a change of variables #147) — after it, difficult is green on the four review pull requests below.
3. Keep algebraic coefficients exact in Risch antiderivatives #136, then Return exact roots from the rule-based backend #141 (which merges Keep algebraic coefficients exact in Risch antiderivatives #136 and needs its compat bound), and Stop calling the deprecated AbstractAlgebra zeros #138 and
   Do not compare nonreal algebraic numbers when taking a sign #140, which are independent of the rest.

I verified on this branch that difficult is green (33 checks pass, the two remaining
failures being the Maxima qa jobs that #146 fixes), and on #146 that its two qa jobs pass
(9 failures instead of 11). Maintainers may of course prefer another order; this is only what
the dependencies suggest.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 84.21053% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 50.66%. Comparing base (8647f0d) to head (38dbab9).
⚠️ Report is 26 commits behind head on main.

Files with missing lines	Patch %	Lines
src/methods/rule_based/rules_utility_functions.jl	84.21%	3 Missing ⚠️
❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #147      +/-   ##
==========================================
- Coverage   50.98%   50.66%   -0.32%     
==========================================
  Files          23       23              
  Lines        4309     4257      -52     
==========================================
- Hits         2197     2157      -40     
+ Misses       2112     2100      -12     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[s-celles]

Some coordination, since I have several pull requests open at once and they all show the same
red checks for reasons none of them introduced.

Two systemic failures were affecting every open pull request:

• the qa jobs of the SymbolicIntegrationMaxima workflow cannot resolve, because
  lib/SymbolicIntegrationMaxima/test/qa/Project.toml still bounds the sub-package at "0.2"
  after Release SymbolicIntegrationMaxima v0.3.0 #143 released it as 0.3.0. That has failed on main since the release, so every branch
  that merges current main inherits it. One-line fix in Allow SymbolicIntegrationMaxima 0.3 in the qa test environment #146.
• the difficult gate fails on a single regression, entry 15
  sin(sqrt(1+x))/sqrt(1+x), where a change of variables discarded the domain of the
  substituted variable. Filed as [RuleBased] change of variables loses the domain of the substituted variable, breaking ∫sin(sqrt(1+x))/sqrt(1+x)dx #145, fixed by this pull request.

The two are complementary: each turns green what the other leaves red. Measured, not assumed —
#146 goes from 11 failures to 9 (its two qa jobs pass), and this branch reports 33 checks
passing with only those two qa jobs left.

A merge order that avoids re-running red CI for nothing:

1. Allow SymbolicIntegrationMaxima 0.3 in the qa test environment #146 and Refresh the Risch baseline for five entries the engine now verifies #148 — one line and five baseline digits, no behaviour change.
2. Keep the domain of a substituted variable in a change of variables #147 (this one) — after it, difficult is green on the four pull requests below.
3. Keep algebraic coefficients exact in Risch antiderivatives #136, then Return exact roots from the rule-based backend #141 (which merges Keep algebraic coefficients exact in Risch antiderivatives #136 and needs the SymbolicUtils = "4.46.8" bound it sets),
   plus Stop calling the deprecated AbstractAlgebra zeros #138 and Do not compare nonreal algebraic numbers when taking a sign #140, which are independent.

Happy to reorder, rebase or split any of these if you would rather look at them differently.
One note for whoever reviews #141: the automated review of it pointed at two real bugs, and
fixing them also required rebuilding rubi_sqrt, because #136 no longer introduces the
exact_sqrt helper that branch was written against. Its description has the details.

Assisted by: AI

[s-celles]

Thanks @ChrisRackauckas for merging