Only apply Base.Sort.SubArrayOptimization when iszero(v.offset1) (#59572)

Fixes #59569

Thanks @N5N3 for finding the bug!

For 1.13, we could re-enable this optimization and propagate the
information to the sub-alg or have the sub-alg's embedded indices be
relative to `kw.lo` rather than absolute. For backports, this minimal
change is more appropriate.

(cherry picked from commit 067b013)

Author: LilithHafner

base/sort.jl

@@ -556,12 +556,15 @@ function _sort!(v::UnwrappableSubArray, a::SubArrayOptimization, o::Ordering, kw
     @getkw lo hi
     # @assert v.stride1 == 1
     parent = v.parent
-    if parent isa Array && !(parent isa Vector) && hi - lo < 100
+    if parent isa Array && !(parent isa Vector) && hi - lo < 100 || !iszero(v.offset1)
         # vec(::Array{T, ≠1}) allocates and is therefore somewhat expensive.
         # We don't want that for small inputs.
+
+        # Additionally, if offset1 is non-zero, then this optimization is incompatible with
+        # algorithms that track absolute first and last indices (e.g. ScratchQuickSort)
         _sort!(v, a.next, o, kw)
     else
-        _sort!(vec(parent), a.next, o, (;kw..., lo = lo + v.offset1, hi = hi + v.offset1))
+        _sort!(vec(parent), a.next, o, kw)
     end
 end
 

test/sorting.jl

@@ -1068,6 +1068,11 @@ end
     end
 end
 
+@testset "partialsort! for UnwrappableSubArray with non-zero offset on 1.11 (#59569)" begin
+    a = reshape(6000:-1:1, 1000, :) |> collect;
+    @test partialsort!(view(copy(a), :, 6), 500:501) == [500, 501]
+end
+
 # This testset is at the end of the file because it is slow.
 @testset "searchsorted" begin
     numTypes = [ Int8,  Int16,  Int32,  Int64,  Int128,