Index portable kernels by the tensor's strides instead of assuming row-major - #21828

…21866)

### Summary

Related to #21828 and #21865 (same underlying assumption in the
optimized kernel library).

`aten.native_layer_norm` returns wrong data on a channels-last input,
off by 3.192 against eager PyTorch where it matches exactly on
contiguous input. Nothing errors.

The portable kernel is fine. It carries this, with the reason written
down:

```cpp
// Only support default dim order for now.
// TODO: Support other dim orders.
ET_KERNEL_CHECK(
    ctx, tensor_is_default_dim_order(input), InvalidArgument, ret_val);
```

The optimized kernel has neither that check nor the matching
`tensors_have_same_dim_order`, and `native_layer_norm.out` is mapped to
`torch::executor::opt_native_layer_norm_out` in `optimized.yaml`. So any
build with `EXECUTORCH_BUILD_KERNELS_OPTIMIZED=ON` gets the ungated one.

It needs the guard rather than stride-aware indexing, because it splits
the buffer into `M` rows of `N` contiguous elements:

```cpp
const size_t M = getLeadingDims(input, dim);
const size_t N = getTrailingDims(input, dim) * dim_size;
```

That layout only exists in the default dim order. This copies the two
checks across from the portable kernel so the two agree.

### Test plan

`OpNativeLayerNormTest.NonDefaultDimOrderDies` passes a channels-last
input with `out`, `mean` and `rstd` all channels-last, so the same dim
order check passes and only the default dim order check can reject.
`mean` and `rstd` share the input's rank with the normalized dims set to
1, which the kernel requires before it reaches any dim order check.

The test file is shared by both kernel libraries, so it runs against the
portable kernel too, where it already passes.

…ck (#21865)

### Summary

Follow-up to #21828, which fixes the coordinate-indexed half of the same
defect. These two PRs touch no files in common and can land in either
order.

Five portable kernels accept a channels-last input and return wrong data
without erroring. Three more share the defect but are currently masked
by an unrelated check. Checked against eager PyTorch with only the
memory format differing:

| kernel | contiguous input | channels-last input |
|---|---|---|
| `aten.cat` | matches | wrong, max abs diff 4.141 |
| `aten.pixel_unshuffle` | matches | wrong, max abs diff 3.941 |
| `aten.slice_scatter` | matches | wrong, max abs diff 3.376 |
| `aten.topk` | matches | wrong, max abs diff 2.581 |
| `aten.constant_pad_nd` | matches | wrong, max abs diff 2.526 |
| `aten.cumsum` | matches | rejected, status 0x12 |
| `aten.split_copy` | matches | rejected, status 0x12 |
| `aten.split_with_sizes_copy` | matches | rejected, status 0x12 |

The check that masks the last three is `tensors_have_same_dim_order`,
and it fires only because the exported graph gives them differing dim
orders. Nothing guards the arithmetic itself, so the unit tests below
reach those kernels directly.

These kernels copy in blocks, taking `getLeadingDims` and
`getTrailingDims` around the operating dim as the length of a contiguous
run:

```cpp
const size_t outer = getLeadingDims(out, dim);
const size_t dim_stride = getTrailingDims(out, dim);
```

That run only exists in the default dim order. Under channels-last the
elements after `dim` are not adjacent, so the arithmetic walks the wrong
bytes.

This is the same assumption as #21828, but it needs a different fix.
There the kernels index element by element, so reading the tensor's
strides is enough. Here the algorithm depends on contiguity itself, and
supporting the layout would mean restructuring each loop. So this adds
the guard that `op_addmm`, `op_bmm` and `op_avg_pool2d` already use:

```cpp
ET_KERNEL_CHECK(ctx, tensor_is_default_dim_order(in), InvalidArgument, out);
```

`cat` needed it on each input as well as the output, since it had no dim
order check at all. `slice_scatter` needed `src` in its same dim order
check as well, since the kernel reads `src` as one contiguous run and
only `input` and `out` were covered. `pixel_shuffle` already carries
this exact pair of checks, so `pixel_unshuffle` missing them looks like
an oversight rather than a decision.

Note: `cat` and `split` appear in nearly every model, so a channels-last
program that runs today would start failing instead of returning wrong
numbers. That still seems better than silent corruption, but happy to
restructure the loops to support the layout instead if that's preferred.

`native_batch_norm` uses the same helpers but is not affected, since it
checks `is_contiguous_dim_order` on the input directly. `select_scatter`
and `unfold_copy` are affected and are left to a follow-up.
`select_scatter` carries only the same dim order check, which passes
when a rank-5 input and a rank-4 `src` are both channels-last, because
`is_channels_last_dim_order` accepts 4 and 5 dims. `unfold_copy` has no
dim order check at all. The same block arithmetic appears in the
optimized `layer_norm`, fixed in #21866, and in the quantized
`dequantize`, which #21517 covers.

### Test plan

A `NonDefaultDimOrderDies` test per kernel. Each passes a uniformly
channels-last set of tensors, so the existing same dim order check
passes and only the new guard can reject. Reverting the eight kernel
sources while keeping the tests fails all eight.

This also adds `op_pixel_unshuffle_test.cpp` to
`kernels/test/CMakeLists.txt`. It is registered in `targets.bzl` but
missing from the CMake list, so those tests do not run in a CMake build
and the new one would not either. Ten other op tests are missing the
same way, and I have left those alone to keep this to one change.



cc @larryliu0820 @manuelcandales @JakeStevens