[SM6.10] LinAlg execution tests: wave size, ColumnMajor and uniform-expectation coverage gaps

Three coverage gaps in the SM6.10 LinAlg execution tests, all verifiable from the
tree.

selectMatrixConstructionWaveSize returns the first wave size the
MatrixConstruction query accepts, scanning upward from 4, and every runner pins
that value with FORCED_WAVE_SIZE. No test forces a literal size, so on a device
supporting several we only ever exercise the narrowest. A lane-to-element mapping
that is wrong only at a wider wave would pass every test we have.

MatrixLayout::ColumnMajor never reaches the GPU: every execution test sets
RowMajor, so a ColumnMajor descriptor load is unexercised. Separately, the
multiply and accumulate tests use uniform fills — in
MatMatMul_Wave_16x16x16_F16, AFill=2.0 and BFill=3.0 with K=16 makes
every expected cell 96 — and a uniform expectation cannot detect a permutation,
aliasing or misplacement of any kind.

Proposed: have the selector target a requested wave size and skip cleanly when
unsupported; add element-access variants at each supported size, including one
that drains a MultiplyAccumulate accumulator and asserts the coordinate map
covers the tile; add ColumnMajor-load round trips; and convert the uniform-fill
multiply tests to asymmetric inputs checked against the CPU oracle.

Note that proposal 0035 permits an implementation-specific and even aliasing
index-to-coordinate mapping, so the assertion that matters is that Get(i)
returns the value living at GetCoordinate(i) and that every cell is named —
not that the mapping takes any particular form.

Start in the SM6.10 LinAlg execution tests, locating selectMatrixConstructionWaveSize and MatMatMul_Wave_16x16x16_F16. Review how runners set FORCED_WAVE_SIZE and RowMajor, then run the existing execution tests to establish baseline behavior. Done means supported wave sizes, ColumnMajor loads, asymmetric CPU-oracle checks, and accumulator coordinate coverage are tested while unsupported sizes skip cleanly.