Fix QuantizedBlockLoader::load_safe bounds check comparing wrong field

[katnoria]

Summary

QuantizedBlockLoader::load_safe's reduction_dim == 1 branch
(mlx/backend/metal/kernels/quantized.h, load_safe) checks

if (reduction_dim == 1 && bi >= src_tile_dim.x) {

bi indexes BROWS — the loader's output axis (M for the activation
loader, N for qmm_t's weight loader), not the reduction axis. Every
call site passes the valid-BROWS count in src_tile_dim.y, by
convention: qmm_t_impl calls with short2(BK, num_outs),
affine_gather_qmm_rhs with short2(k_remain, tgp_bn). Both put the
BROWS-count in .y. The guard compares against .x instead — the
BCOLS/K-tile-width count.

Why this was never observed

Every qmm_t/gather_qmm_t instantiation shipped to date has
BROWS == BK == 32 (the loader's tile is always square in that
dimension), so .x == .y in every existing call and the miscompared
field was interchangeable with the correct one — the check has been a
no-op, correct "by luck," not by construction. It stops being a no-op the
moment a caller sets BROWS != BK — e.g., a wider output tile than
K-tile — at which point some in-range output rows fall on the wrong side
of the miscompared bound and get force-zeroed by an unrelated check
instead of the intended rows.

The fix

One-line change: compare against src_tile_dim.y instead of .x. Zero
behavior change for every existing BROWS==BK instantiation (confirmed:
.x == BROWS there too, so the two fields were interchangeable in
exactly that case) — this is a pure latent-bug fix, not a behavior change,
for the kernel configurations that ship today.

Testing

python -m unittest test_quantized -v (run from python/tests/): 34/34
pass, both MLX_METAL_JIT=ON and the default MLX_METAL_JIT=OFF build —
output-identical before/after, as expected for a fix that's a no-op on
every shipped instantiation. Also verified by a broader stress sweep
(~550 shape/dtype/group_size/bits combinations against a
dequantize+dense-matmul reference) with no behavior change relative to
unmodified upstream/main.

This is being split out from a separate, larger change (a qmm_t tile-size
dispatch fix) that is what actually exercises the BROWS != BK path and
is what surfaced this bug — see #4204 — but this fix stands on
its own and is correct independent of whether that change lands.

[zcbenz]

There are already quite a few PRs on this.