feat(optim): add Conv channel-affine folding

[xieofxie]

Summary

Add an opt-in conv-channel-affine-folding algebraic rewrite that folds safe scalar or channel-wise constant Mul/Add operations into Conv weights and bias.

The rewrite supports direct affine chains and channel routing through static Split/Slice and channel-preserving Reshape/Squeeze/Unsqueeze operations. It conservatively rejects dynamic shapes and constants, shared or public intermediate tensors, overlapping channel ranges, unsupported broadcasts, and non-floating Conv parameters. Multiple independent matches are handled, generated parameters use collision-safe names, dead constants and replaced initializers are pruned, and repeated optimization is idempotent.

BatchNormalization folding from the source change is intentionally excluded.

Why this is not a pattern rewrite

The current pattern rewriter replaces a fixed, removable source subgraph with a fixed target topology whose source and target schemas must match. Conv channel-affine folding requires different behavior:

• It computes replacement Conv weights and bias from matched initializers and affine values.
• Routed matches can span a variable number of Split, Slice, and shape-only view branches.
• Affine updates from disjoint branches must be aggregated by Conv output-channel interval before changing the Conv.
• Routing nodes may need to remain in the graph while only terminal Mul/Add nodes are removed and router outputs are rewired.
• Shared or externally visible intermediates must make only the affected candidate ineligible rather than treating the entire routed topology as a removable pattern.

These requirements are match-parameterized parameter surgery over partially retained topology, not fixed subgraph substitution. Supporting them as a pattern would require broader framework capabilities for mutable initializer transforms, variable topology, partial-match retention, and cross-branch aggregation. Therefore this remains a focused algebraic rewrite.

[xieofxie]

Simple example

Assume a Conv produces 10. The graph then multiplies it by 2 and adds 3:

Conv result: 10
Multiply:    10 * 2 = 20
Add:         20 + 3 = 23

Instead, ModelKit changes the Conv's stored numbers:

new Conv weight = old Conv weight * 2
new Conv bias   = old Conv bias * 2 + 3

The modified Conv directly produces 23, so the separate Mul and Add are no
longer needed.

[DingmaomaoBJTU]

Reviewed the Conv channel-affine folding. The core algebra is correct and nicely conservative — I checked direct chains, Split/Slice routing, channel-preserving views, nested slices, partial (single-branch) folds, shared-weight Convs, multi-consumer terminals, and chained Conv→Mul→Conv, and they all stay numerically exact; the 17 tests pass. A few non-blocking notes below.

[DingmaomaoBJTU]

Re-reviewed 4209ab2 (fix: preserve affine precision and metadata). Both earlier points are resolved and verified:

• Affine precision — calculation_dtype = np.result_type(weight_dtype, np.float32) is now threaded through _collect_affine_chain / _collect_routed_affine_candidates, so the accumulators no longer truncate to float32. My repro (float64 scale = 1 + 2**-30) now folds to 1.0000000009313226 exactly instead of 1.0, and test_float64_affine_values_preserve_weight_precision locks it in. float16 still accumulates in float32 as expected.
• Stale value_info — _prune_stale_value_info cleanly drops metadata for tensors no longer produced (only removes names absent from inputs/initializers/node outputs), and the new assert not transformed.graph.value_info guards it.

All 18 algebraic tests pass and my direct/routed/view/nested-slice/shared-weight/chained probes stay numerically exact. The one remaining note (the per-fold _GraphIndex.build) is a low-priority perf item and safe to leave. LGTM from my side.