Fix Metal sort for arrays with negative strides

[reckylurker]

Fixes #4225.

Proposed changes

mx.sort, mx.topk, and mx.partition on Metal GPU returned zeros for non-first rows when called on arrays with negative strides (e.g. x[::-1, :]).

In single_block_sort and multi_block_sort, set_input_array binds Metal buffer 0 starting at a_buf + in.offset(). When non-sorted axes have negative strides, elem_to_loc in MSL computes negative relative pointer offsets for subsequent rows (tid.y = 1 -> -4 elements), attempting to read memory prior to Metal's bound buffer window. Metal's GPU memory protection traps these out-of-bounds reads and outputs 0.0f.

Matching NumPy's behavior when sorting negative-strided views, gpu_merge_sort now checks for negative strides and creates a temporary contiguous GPU copy via contiguous_copy_gpu(in, s). Zero-copy execution is fully preserved for standard contiguous arrays, transposed arrays (x.T), and positive strided views (x[::2, :]).

Added test_strided_negative_stride_sort in python/tests/test_ops.py.

Checklist

• I have read the CONTRIBUTING document
• I have run pre-commit run --all-files to format my code / installed pre-commit prior to committing changes
• I have added tests that prove my fix is effective or that my feature works
• I have updated the necessary documentation (if needed)

[zcbenz]

The bug is true but a correct fix should get the root cause fixed rather than working around the problem by doing a copy.

[zcbenz]

Closing in favor of #4252.