merge_add (add+add) lacks the review-fix hygiene: missed cancellations and associativity-dependent forms

[petlenz]

Summary

Deferred finding from the adversarial review of PR #386/#387 (value-correct, so not blocking): merge_add — the add+add merge in include/numsim_cas/functions.h — applies find_like per child but has none of the hygiene the dispatcher paths gained in the review fixes:

• no reverse-direction probe (stored bare x, incoming child 2*x from the other add): (2*x+y) + (z + (-2*x)) → 2*x+y+z-2*x — the cancellation is missed;
• no zero filter / degenerate collapse after combining;
• consequence: (a+b)+c vs a+(b+c) can produce structurally different, ==-unequal results even though both evaluate identically.

How to fix

Route merge_add's per-child insertion through the same helper the dispatchers use (merge_and_finish-style: probe both directions, filter zero_type, collapse empty/single-child, invalidate_hash). The helper currently lives on add_dispatch; hoist it to a free function next to merge_add so both share one implementation.

Tests

• (2*x+y) + (z + (-2.0)*x) → y+z (scalar), plus the tensor/t2s twins.
• Associativity property: for random 3-term sums over {bare, c*term, -term}, (a+b)+c == a+(b+c) structurally (extends the algebra fuzzer planned in epic [epic] Canonical form + hash-consing: make expression identity structural, not conventional #379).

[petlenz]

Round-2 review addition: the reverse-negative direction is the remaining unmerged case — (y-x)+x → x+y-x, (tr B - tr A)+tr A and the tensor twin stay unmerged (value-correct). The dead t2s template that nominally handled it was deleted in the #386 stack (closes #370); the fix belongs in the shared core dispatch next to the bidirectional like-term probe added there.

[petlenz]

Status update after review rounds 5–12 on the #386–#410 stack (branch fix-340-hash-identity-sweep):

Fixed by the rounds (most of this issue's original scope):

• The insertion helper was hoisted exactly as proposed: add_insert_signed is a free function in functions.h, shared by merge_add, merge_and_finish, and every dispatcher-side insert (insert_signed<Traits> wrapper in simplifier_common.h).
• merge_add now has: the exact-negation probe (round 7), used-set gating so an rhs child is consumed once (round 8), zero-filtered inserts + cancelled-coefficient dropping (rounds 8/9), and the callers finish through finalize_add/collapse — including the tensor caller (rounds 8/9).
• The original repro (2*x+y) + (z + (-2.0)*x) now cancels (coefficient-blind hash makes -2*x a like term of 2*x, and like-term combine + zero filter fold it away).
• Associativity for the tensor domain: A+(B+C) == (A+B)+C (round 11 — the rhs-add nesting is gone).
• Regression tests: RoundSeven/Eight/Nine/Ten/ElevenReview suites in tests/CoreBugFixTest.h.

Still open (rescoped remainder of this issue):

1. Non-exact negative like-terms never merge: only EXACT negation pairs cancel. 2*t + (-(3*t)) stays unreduced, because neg(c*T) is hash-tagged differently from mul{c,T} so find_like can't see it. A round-12 structural fuzzer found 221 associativity-dependent ==-mismatches, all attributable to this shape (all value-correct). Fix direction: normalize neg(mul) to a negative coefficient at construction (one canonical spelling), or teach find_like/is_like a guarded neg(mul) unwrap.
2. Sub-side add−add like-term matching uses a raw map find: (x+5*y+z) - (x+4*y) cancels x but leaves 5*y-4*y unmerged — the n_ary_sub_dispatch::dispatch(add_type) child loop matches by map-key equivalence (hash + coeff tie-break) instead of find_like, so like terms with different coefficients never meet. Mirror the add-side find_like probe (with the deep-equality guards from Raw hash_value() equality used as identity in simplifiers — X+pow(X,2)→2*pow(X,2), X+2*X→4*X, X*(2*X) drops the 2, sin(a)−sin(b)→0 #340).

Both remainders are value-correct canonicalization gaps confirmed by compiled probes at stack top (1692 tests green).