perf: fix granularity search to try k > 1 for MatMul subgraphs

[melroyanthony]

P0: Fix k=1 pathology in granularity search

Problem

The granularity search currently selects k=1 for mega-fused subgraphs containing MatMul ops. This creates K_full k-steps per spatial tile, each loading tiny strips (h1 + 1w elements) and doing minimal compute (base_cost/K_full). The result is pathologically memory-bound execution.

Example (Benchmark 1): K_full=512, k=1 → 512 k-steps per tile, each loading 544 elements. With k=512, only 1 k-step loading 278,528 elements — but total memory traffic is far lower because strips aren't reloaded 512 times.

Expected Impact

10-100x improvement on MatMul-heavy benchmarks (1, 9, 13).

Acceptance Criteria

• Granularity search tries k values from K_full down to 1 (powers of 2)
• For each (w, h, k) candidate, computes actual total latency (sum of per-step roofline)
• Selects the (w, h, k) that minimizes total subgraph latency within OOM constraint
• Track A (Rust) and Track B (Python) both updated
• All 15 Rust tests still pass
• Benchmark latencies improve vs current values

Current vs Expected

Benchmark	Current Latency	k used	Expected after fix
1	27,443	1	Significantly lower
9	110,100	1	Significantly lower
13	191,693	1	Significantly lower

[melroyanthony]

Root Cause Analysis

The issue is deeper than just the granularity search. There are two interrelated bugs:

Bug 1: num_k_steps ignores internal MatMuls

subgraph_latency() in latency.rs derives num_k_steps from find_boundary_matmul_k_full(), which returns None if the subgraph's boundary output is from a Pointwise op. This means for a fused MatMul → Pointwise subgraph, num_k_steps = 1 regardless of k — making the k dimension completely ignored.

Bug 2: Pointwise compute incorrectly counted on every k-step

compute_time_per_step() adds base_cost for Pointwise ops on every k-step. Per the problem statement: "For Pointwise operations, since they have no reduction dimension, k is ignored (effectively treating it as 1), and the operation simply executes once per spatial tile." In a fused subgraph with k-steps, Pointwise should only contribute compute on the last k-step (after MatMul accumulation completes).

Correct Execution Model for Mixed Subgraphs

For a fused subgraph containing both MatMul and Pointwise ops with granularity [w, h, k]:

• num_k_steps = ceil(min_K_full / k) (from ALL MatMuls, not just boundary)
• Per k-step (not last): compute = sum(matmul.base_cost * k/K_full)
• Last k-step: compute = sum(matmul.base_cost * k/K_full) + sum(pointwise.base_cost)
• Pointwise output eviction happens on last k-step only

Impact

Fixing both bugs together enables correct evaluation of k > 1 for fused MatMul+Pointwise subgraphs, which is prerequisite for the granularity search finding optimal k values.