Fix multiply's and matmul's Hessians when their children share a subexpression

[dance858]

Fixes #160.

Summary

• Bug: multiply and matmul (chain-rule path) evaluated both children's Hessians and only then summed C + C^T + H_x + H_y with sum_4_matrices_fill_values. When the children share a node, evaluating the second child re-evaluates that node with other weights and overwrites the first child's Hessian before the sum reads it.
• Fix: same as Fix add's Hessian when its children share a subexpression #159 for add. The Hessian pattern comes from sum_n_matrices_alloc with n = 4, and each term is added with sum_n_matrices_fill_add right after it is final (C and C^T first, then each child right after its eval_wsum_hess).
• Not changed: problem.c's Lagrangian Hessian already fills incrementally. The variable × variable fast paths evaluate no child Hessians.
• Performance: the fill does the same work as before (one memset plus four accumulator passes over the same bound maps), plus three inlined values_version++. In a single A/B run against main (Release), multiply (n = 200k, elementwise children) took 1.18 vs 1.16 ms and chain-rule matmul (exp(X) @ log(Y), 60×60) took 20.5 vs 21.5 ms. That's one run each and within the usual layout noise; no repeated runs were done.
• Follow-up: sum_4_matrices_* now has no engine callers and can be dropped from the library later.

Tests

• New test_wsum_hess_multiply_shared_subexpr (mul(log x, exp(log x)) and mul(exp(log x), log x)) and test_wsum_hess_matmul_shared_subexpr (log X @ exp(log X) and exp(log X) @ log X, X 2×2) check against the numerical Hessian with one shared log node.
• Both fail on the old code (multiply: analytical 5.39 vs numerical 2.00; matmul: 5.39 vs −16.0) and pass with the fix.
• All tests pass in Debug (306, SP_TRACK_MEMORY=ON) and Release (307).

🤖 Generated with Claude Code