The e-graph moves from a harness into the kernel, behind an explicit opt-in

[Rafael-SOWNet]

Summary

#746 tier 2's row names two things remaining "in dependency order": no production caller for the reversible-rule mechanism, and folding on insertion. This closes the second (already proven in the work/egraph measurement harness — 7/16 → 15/16 corpus expressions saturating under the full rule set, neutral-element churn 13–34% → 0%) and gives the first a real, narrowly-scoped answer.

• EGraph — the harness's e-graph design (union-find, hash-consed e-nodes, congruence rebuild, neutral-element folding on insertion) moved into the kernel unchanged, as an internal type.
• MatchPattern.Construct → ConstructNode — widened from private to internal (as ConstructNode) so extraction rebuilds a node's type from the same registry the pattern-matching layer already trusts, instead of a second, independently-drifting operator list.
• Transformation.EqualitySaturation(WorkBudget, CostModel) — the production caller. Builds an e-graph from the input, fires only rules whose RewriteRuleGrowth is Collects or Rearranges (withholding Expands and Unknown — unproven isn't the same as safe), bounded by AngouriMath.Core.Budgets.BudgetLedger (the same budget type Gröbner elimination already answers to), and extracts the cheapest candidate under the given CostModel.

Nothing runs this by default — same standing as RationalCanonicalization/Canonicalization. Simplify applies a rule set once and moves on; equality saturation deletes exactly that ordering, which is why it needs a budget rather than a pass count.

What this is not, stated in the doc comment rather than left implicit: the harness this is built from enumerates a class's terms and rewrites each — it finds what e-matching would, but by materialising terms a real e-matcher never builds. That instrument moved here unchanged; a production e-matcher over MatchPattern is not this, and tier 2 still names it as the production caller's other missing half. Nor does a 16-expression textbook corpus settle whether this generalises to what Simplify is actually asked to handle — the budget parameter is the honest acknowledgment of that, not a solved problem's formality.

A flake chased down, not papered over

a / b / c rewritten to a / (b * c) occasionally failed a numeric equality check under dotnet test, and never once across 2,300+ raw concurrent calls to the same code in an isolated process. Both chains are the same value reached by differently-ordered complex divisions; comparing them with the exact equality ExpressionNumerical.AreEqual uses is comparing two floating-point rounding paths, not the value each settles on. Fixed by verifying against Entity.EqualsImprecisely — the tolerance this library already has for exactly that comparison — rather than loosening what the transformation itself promises.

Test plan

• TDD throughout: EGraph's union-find, hash-consing, congruence rebuild, and neutral folding (all 5 operator cases, including the 2 — 0 - x, 1 / x — that must not fold) each have a test that failed for the right reason before the fix.
• Transformation.EqualitySaturation tested for its stated relation/soundness, that it declines to change an already-cheapest expression, that it never throws under a starved budget, and — across the existing TransformationTest.Corpus — that it never changes the value it claims to preserve (numerically, at several real check points).
• Full suite: 8838 tests, 8824 passed, 14 skipped (pre-existing), 0 failed.
• PublicApi.txt regenerated for the one new public member (Transformation.EqualitySaturation) — diff is exactly that one line.

🤖 Generated with Claude Code

[Rafael-SOWNet]

Added a follow-up commit: while working on this, tried extending Reversed/IsReversible onto the public RewriteRule the same way Growth is exposed there (tier 2's own text names the inverse-pair table as needing exactly that). Measured against the live registry before shipping it, found it changes nothing for 29 of 30 sets (only RationalizeDenominator flows through AsAddressable(), and its rules are non-reversible anyway), and reverted the code rather than ship something inert. Docs/Contributing/InversePairTable.md records what a real fix would need, so the next attempt starts from there instead of re-discovering it.

[Rafael-SOWNet]

A code review of this PR and #1102 found fifteen issues before either had a human reviewer. Two were confirmed wrong-answer bugs and are fixed in the latest commit, each with a regression test at the EGraph level and at this PR's own Transformation.EqualitySaturation level:

• Codomain loss on every reconstructed node. EGraph.Extract rebuilt through a bare constructor (MatchPattern.ConstructNode), which restores nothing — the rest of the codebase copies Codomain forward on every Replace via a New(...) helper. A Codomain-narrowed subexpression (sqrt(-1) restricted to the reals evaluates to NaN, unrestricted to i) silently reverted to its type's default codomain, unconditionally, whether or not any rule fired.
• EulerIntrinsic identity loss. The e-graph keys a leaf by its printed form, and Entity.Constant.EulerIntrinsic prints identically to the ordinary named constant e — the two are Equals-equal by design but only EulerIntrinsic is meant to stay outside what a binder over the name e can capture. Re-parsing the printed form silently substituted the named constant, invisible to every equality check and only wrong at a binder (sum(ln(x), e, 1, 2) after a round trip through the graph).

The other thirteen findings are recorded in EqualitySaturationReviewFindings.md rather than fixed here — several (a Providedf-wrapped result unioned onto a dead end, Extract's 14-type reconstruction whitelist, a NaN CostModel corrupting comparison) point at the same underlying gap: the e-graph's node model has nowhere to carry anything beyond raw tree shape. That's a design question worth its own pass rather than a patch alongside these two. The rest (budget-charge timing, an unused NodeTypes pre-filter, a duplicated operator-type list, RewriteRecording blindness, SimplifiedRate cache staleness on #1102) are each small and independent, and are listed there for whoever picks one up next.

Full suite green: 8828 passed, 14 skipped (pre-existing), 0 failed.