Check threadgroup size in the 1-pass sdpa_vector dispatch

[apocryphx]

sdpa_vector dispatches a fixed 1024-thread threadgroup but never validates it against the pipeline's maxTotalThreadsPerThreadgroup. Both dispatches in sdpa_vector_2pass already call check_kernel_threadgroup_size; this adds the same call to the 1-pass path.

Today this is latent — I'm not aware of a head dim currently routed to the vector kernel that trips the limit on any shipping device. What makes it worth a line is how the failure presents when it does trip. An over-limit dispatchThreadgroups is dropped by the driver: the kernel never runs, no error is raised at any level, and the output buffer is returned untouched — all zeros. There is no signal from MLX at all; MTL_DEBUG_LAYER=1 is what eventually surfaced it for me.

I hit it while prototyping a d=512 instantiation for #3885 on an M1 Max, where register pressure caps both d=512 pipelines at 832 threads (maxTotalThreadsPerThreadgroup = 832 for sdpa_vector_bfloat16_t_512_512, vs 1024 for ..._256_256 on the same device). The 2-pass path threw a clear exception from the check that's already there. The 1-pass path silently returned zeros, and I spent a while trusting benchmark numbers from a kernel that never ran.

The cost is one comparison per dispatch on an already-cached pipeline object. The benefit is that a register-limited pipeline fails the same loud way on both vector paths instead of one of them producing wrong results quietly. That protection is independent of #3885 — it applies to any future head dim, kernel change, or device whose register allocation lands under 1024.

No test: triggering this requires a pipeline that register-limits below 1024, which is device- and head-dim-specific and not reproducible in CI. The two existing check_kernel_threadgroup_size call sites are untested for the same reason.

[zcbenz]

It makes sense adding the check, thanks!