fix(store): disk-lane numpy view imports were the machine-killer's other half

Commit 21fd6f909 fixed the L1 extraction lane, and the instrumented curve
went flat with the disk store disabled -- but with it enabled, live Metal
still climbed 20 -> 159GB. The disk write-through builds its per-block L2
payloads in _numpy_block_slice's generic positional branch, where the
non-contiguous view is aliased through a local before import:

    ks = np_k[:, :, slice_start:actual_end, :]
    ks = mx.array(ks)        # base-buffer-sized Metal import

so neither the site sweep nor the source-pin regex (which matched only the
inline mx.array(np_k[...]) shape) caught it. Each of the 16 KV layers per
block imported a ~30MB base-span buffer, and the ("kv", ks, vs) tuples sit
in pending_disk_writes until the whole store loop finishes: ~0.85GB per
block, ~159GB across 163 blocks. Measured live: L1 payloads were 8.0MB per
block (16 kv + 48 skip) while act still climbed to 97GB -- the giants were
all in the deferred disk payloads.

Routed through _mx_from_np_slice, along with the remaining bare imports in
both block-slice functions (rotating terminal/previous-window tk/tv, ZAYA
_to_mx_tree) -- ascontiguousarray is a no-op for already-contiguous inputs.
The source pin now tokenizes both functions and rejects ANY bare mx.array()
call there, comments and docstrings excluded, so an aliased import can
never hide again.