[C++] winsorize on a sliced array ignores the offset: wrong rows come out null

**Describe the bug**

`pyarrow.compute.winsorize` on an array with a non-zero offset returns nulls at positions that hold
values and values at positions that are null, even with limits of 0.0 and 1.0, which should return
the input unchanged. The same values in an array with offset 0 come back unchanged.

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

```python
import pyarrow as pa, pyarrow.compute as pc

flat = pa.array([1.0, 2.0, None, 4.0, None, 6.0, 7.0, 8.0], pa.float64())
sliced = flat.slice(2, 5) # [None, 4.0, None, 6.0, 7.0]
copy = pa.array(sliced.to_pylist(), pa.float64())

print("sliced", pc.winsorize(sliced, lower_limit=0.0, upper_limit=1.0).to_pylist())
print("copy ", pc.winsorize(copy, lower_limit=0.0, upper_limit=1.0).to_pylist())
```

Output:

```
sliced [0.0, 4.0, None, 6.0, None]
copy [None, 4.0, None, 6.0, 7.0]
```

The null pattern of the sliced result, `[valid, valid, null, valid, null]`, is the parent's validity
bitmap read from bit 0 (`flat[0..5]` = valid, valid, null, valid, null) rather than from bit 2.

**Expected behavior**

`winsorize(sliced, 0.0, 1.0)` returns `[None, 4.0, None, 6.0, 7.0]`, the same as for the copy.

**Component(s)**

C++, Python

Start by reproducing the issue with the Python example through the pyarrow.compute.winsorize entry point, comparing the sliced array with the offset-zero copy. Trace the C++ implementation used by that entry point and verify that winsorize(sliced, 0.0, 1.0) preserves the sliced values and null bitmap, matching the expected output.

Written by the indexing model from the issue text.