prevent reduce jvp from reordering reduction

[mattjj]

fixes #32474

[mattjj]

Passes on CPU and TPU but not GPU? :think-cry:

[tomsmeding]

While I posted the issue that led to this PR (thanks!), I don't really use JAX in practice, so I'm not sure I'm the right person to review or test any of this. :)

Just one thought I have: it's possible that the new strided version is slower than the original. The original had only non-strided slices, which are probably compiled to a memcpy-like operation at some point; with striding, the memory gathers cannot be vectorised nearly as well and may well be slower.
On a high level, this is not surprising: it is known in the (functional) parallel computing world that a parallel reduction can be faster if it is allowed to assume commutativity. This is, for example, also why Futhark has a separate reduction primitive for commutative operators.

[mattjj]

Great points, @tomsmeding ! Yes I think if we knew of some users (or developers) who were interested in this, we would add more structure here, like separate commutative- and noncommutative-reduces.