perf(einsum): memoize the symmetry-aware path rebuild instead of redoing it per call

[spMohanty]

Rescoped from #26. The original issue targeted pre-cache extraction work; that ask is stale (_symmetry_fingerprint and inner_sym no longer exist, and the measured win there is ~1.7 us/call, below this hardware's A/B noise floor). The real cost on the same lines was introduced a month after #26 was filed, by 8d2005fc23 / d0891da8bb.

The bug

_get_path_info fetches path_info from _path_cache, then — whenever any operand carries symmetry or two operand positions alias the same array — discards it and re-runs a full opt_einsum.contract_path plus build_path_info oracle group enumeration. That rebuild fired on every call, so the path cache reported a 100% hit rate while the work it exists to cache was redone anyway.

Ordinary code reaches it: fnp.zeros((n, n)) returns a SymmetricTensor carrying SymmetryGroup([1, 0], axes=(0, 1)), and x @ x enters via identity_pattern. It reaches every entry point routing through einsum, including matmul and @.

The fix

The rebuild is a pure function of the _path_cache key — the dummy operands it contracts are materialized from shapes alone, and the aliasing comes from identity_pattern — so it is memoized on exactly that key. The optimizer label is threaded in as a key component rather than recomputed, so optimize=False still falls through to the upstream _path_type.

build_path_info is the expensive half (162 us vs 6 us for contract_path at 64x64), so caching only the path search would not have helped.

Measured, at a verified 100% cache-hit rate (64x64)

case	before	after
dense (a, b)	65.8 us	65.9 us
aliased x @ x	242.5 us	68.4 us
zeros((n, n)) operand	268.7 us	72.4 us

Both symmetric cases land within ~10% of the dense call instead of 3.7-4.1x it. The dense path is untouched.

The removed wall time was billed to flopscope_overhead_time_s, which docs/reference/cost-model.md:913-922 requires to stay bounded and not caller-inflatable. _resolve_optimize_for_k could not see it: it gates on k >= 8 and watches contract_path, while this fired at k=2 inside build_path_info.

Behavior preservation

• Billed FLOPs and result values bit-identical across dense, aliased, symmetric-2D, rank-3, 3-op chain and matmul cases.
• Per-step input_groups / output_group / inner_group — what the rebuild is load-bearing for — unchanged.
• Sharing the memoized PathInfo matches the dense path, which already shares its StepInfo objects across calls; FlopscopePathInfo.from_inner rewrites step.flop_cost on every call either way.

Tests

Two driving tests assert a warm aliased/symmetric contraction performs no further path search — both watched failing first, with exactly 5 extra searches over 5 calls. Three guard tests pin that the memo key still separates symmetric from dense and aliased from distinct, and that per-step groups survive. All five fail if the key is weakened.

Full suite: 10171 passed. The 13 failures and 3 errors are pre-existing on main — identical set with this change stashed.