Fix signed-integer overflow in convolution shape arithmetic

[eyupcanakman]

Follow-up to #3611, which was closed as mostly fixed with an invitation to open PRs for whatever still hit UB. #3524 handled the Metal and CUDA sides. The shape arithmetic itself is still 32-bit.

conv_out_shape computes 1 + dilation * (dim - 1) and the padding sum in 32 bits. conv_transpose_general works out all of its padding in 32 bits before the nested conv_general validates anything, and the backward pass repeats those same formulas in Convolution::vjp and conv_weight_backward_patches. Extreme but in-range int32 parameters wrap rather than raise. On an 8x8 input with a 3x3 weight, mx.conv_general(..., kernel_dilation=2**31-1) returns a 10x10 output.

These now compute in int64_t and narrow through safe_cast, the same way #3524 and #3604 did. Convolution::vjp calls the 64-bit dilate_size helper rather than repeating the formula, which is what #2601 pulled it out for.

Most of those inputs raised nothing before. The ones that did move from std::invalid_argument to std::overflow_error, so Python raises OverflowError where it used to raise ValueError. In-range convolutions are unchanged.

Built CPU-only with -DUSE_UBSAN=ON. The added test drives 15 signed-overflow reports before the fix and none after, and 9 of its 11 assertions fail without it. Full C++ suite passes 245/245, Python 784 passed.

Two things #3611 also lists are left alone. The lcm jump-table sizes are in the Metal backend, and the dim + 1 half of its negative-padding item is in normalize_slice, reachable from mx.slice with no convolution involved.

[zcbenz]

Thanks!