TileOP: fix RedRows per-PE semantics for Local-A/Shared-B groupM

[VV0003]

Fixes the group_M assertion failure reported for TMATMUL(d, a, b, options, groupM) with CubeM32 tiles and group_M=128.

Root cause

The explicit-groupM overloads computed the reduction/output row count as:

RedRows = cooperative ? cooperative_group_m_rows_per_pe(EffectiveM) : EffectiveM;

For Local-A/Shared-B, EffectiveM = A::ValidRow which already is the per-PE shard size (M_per_PE per ADR-0100) — each PE holds a full [M_per_PE, K] block. Feeding it back through rows_per_pe():

• M_per_PE=32 (CubeM32, group_M ∈ 65..128) → rows_per_pe(32)=16 → 32 != 16 → the reported compile failure
• M_per_PE=16 (CubeM16, group_M ≤ 64) → rows_per_pe(16)=16 → passed only by coincidence, masking the bug

Fix

Only Shared-A (where EffectiveM is the core-total group_M) derives its per-PE block via rows_per_pe(); Local-A uses the shard size directly:

RedRows = is_shared_tile_v<A> ? rows_per_pe(EffectiveM) : EffectiveM;

Verification

• CubeM32 Local-A + Shared-B + group_M=128: compiles; disassembly shows LB0 carrying the runtime group_M (register), N/K immediate-form (C.B.DIMI)
• CubeM16 + group_M=64: unchanged
• GroupMatmul / SharedMatmul / TMatmulAccFullOptions / PostProcessCombos / TGEMVAllOptions fixtures and unittest 40/40 all clean

Fixes the assertion analyzed in the linked report (Local-A/Shared-B explicit-groupM path).