[C++] binary_slice with its default `stop` raises "Negative buffer resize"

[singhpratech]

Describe the bug

pyarrow.compute.binary_slice(arr, start) with stop left at its default raises
ArrowInvalid: Negative buffer resize once a value is longer than a few hundred bytes. Passing an
explicit large stop works, and utf8_slice_codeunits handles the same default correctly since
#36575; the binary kernel still has the overflow in its output-size arithmetic.

pyarrow 25.0.1, Python 3.13.9, macOS 26.6 (arm64), wheel from PyPI.

import pyarrow as pa, pyarrow.compute as pc

b = pa.array([b"abcdef", b"x" * 300], pa.binary())
print([len(x) for x in pc.binary_slice(b, 1, 1000).to_pylist()])   # explicit stop: fine
print([len(x) for x in pc.utf8_slice_codeunits(pa.array(["abcdef", "x" * 300]), 1).to_pylist()])
print(pc.binary_slice(b, 1).to_pylist())                            # default stop

Output:

[5, 299]
[5, 299]
Traceback (most recent call last):
  ...
pyarrow.lib.ArrowInvalid: Negative buffer resize: -4

Expected behavior

binary_slice(b, 1) returns [b"bcdef", b"x" * 299], as utf8_slice_codeunits does for the string
equivalent.

Related: #34929 (umbrella for slice-option overflow), #36575 (the utf8 fix).

Component(s)

C++, Python

[singhpratech]

The overflow is in SliceBytesTransform::MaxCodeunits (scalar_string_ascii.cc on main):
(opt.stop - opt.start + opt.step - 1) / opt.step with the default stop of
numeric_limits<int64_t>::max() wraps negative when start > 0, and that negative bound is what
becomes "Negative buffer resize". #36575 fixed the same expression for utf8_slice_codeunits;
the byte-slice transform still has the original form.