[Codegen][CPU] Fix RHS indexing map in materialize-encoding inner_tiled lowering. (#24325)

The CPU encoding-materialization path (`lowerContractionOpToInnerTiled`)
emits an `iree_codegen.inner_tiled` op with the standard matmul indexing
maps `[(d0, d2), (d2, d1), (d0, d1)]`, but the RHS pack it lowers to
uses `outer_dims_perm = [1, 0]` so the packed RHS comes out with outer
dims in `(N_iter, K_iter)` order — i.e. mmt4d-style, not standard-matmul
style. The two interpretations of the same operand shape disagree, and
the inner_tiled verifier rejects the op with:

    error: 'iree_codegen.inner_tiled' op shape does not match
           iteration bounds

Switching the RHS map to `(d0, d1, d2) -> (d1, d2)` matches what the
pack actually produces and lets the verifier project a consistent
iteration domain across all three operands. The semantics are still a
valid contraction (one parallel + one reduction on each input, two
parallels on the output), just with the RHS walked in mmt4d order.

Without this fix, data-tiled `linalg.matmul` -> `inner_tiled` lowering
on CPU fails the verifier on the very first dispatch and never gets near
codegen; with it, end-to-end compile gets past verification all the way
to bufferization (where a separate, pre-existing pipeline gap takes
over: there is no CPU pass yet that vectorizes/lowers `inner_tiled`
before bufferize).

Progress towards #24323