GH-53519: [Python] Use 64-bit counters in string buffer factories

[Mola-maker]

Rationale for this change

Fixes #53519.

StringArray.from_buffers() and LargeStringArray.from_buffers() reject valid arrays with counters above INT32_MAX, while Array.from_buffers() accepts the identical buffers and reads the correct final value. The specialized helpers narrow length, null_count and offset to C int, even though Arrow ArrayData uses 64-bit counters.

What changes are included in this PR?

Use int64_t for all three counters in both factories. Extend normal string/binary round-trip tests to both classes and add six valid large-counter regressions with real sparse mappings, generic-factory controls and final-value checks. The large tests use the existing large_memory group and import mmap inside the test so unsupported platforms can skip them without affecting collection. No buffer layout or runtime dependency changes.

Are these changes tested?

• Compiled both original and candidate pyarrow.lib bindings from source against the official PyArrow 26.0.0 C++ SDK; all 29 packaged pxd ABI descriptions matched. The whole C++ SDK was not rebuilt.
• Ubuntu/Python 3.12.14/GCC 15.2 and native Arch/Omarchy/Python 3.14.8/GCC 16.2.1 each reproduce six specialized OverflowErrors with six valid generic controls. The fixed bindings produce six valid specialized arrays, including correct final values and null counts.
• Each environment: 8 focused tests passed with PYARROW_TEST_LARGE_MEMORY=1; full array module: 332 passed, 40 skipped using default groups. All six new native regressions fail against original source.
• git diff --check passes. Independent Codex review found no confirmed blockers. Final issue/PR searches found no equivalent fix.
• The PR base was updated after main added unrelated Parquet encoding support; the entire Python subtree is unchanged from the source used for validation.

Exact dependencies, installation logs, source-build logs, hashes and reproduction programs.

These unedited screenshots come from omarchy capture screenshot fullscreen save in the same running disposable Arch/Omarchy guest. The terminal program reruns the actual Arrow calls against the installed native binding and prints its SHA256. Sparse valid buffers reserve address space while process RSS remains around 57–79 MiB.

Before:

After:

Are there any user-facing changes?

The specialized string factories now accept valid 64-bit counters consistently with the generic factory. Existing valid inputs and string offset-buffer widths retain their behavior.

Was AI used for this PR?

PR code and description written by:

• Human
• AI

Reviewed before submission by:

• Human
• AI
• Not reviewed

Code, tests and descriptions used Codex, with independent AI code review and actual source-build/runtime validation in both environments. No human code review is claimed.

• GitHub Issue: [Python] String array buffer factories reject valid 64-bit counters #53519

[github-actions]

⚠️ GitHub issue #53519 has been automatically assigned in GitHub to PR creator.

[thisisnic]

Thanks for the PR. I’m closing it because Arrow’s contributor guidelines require that AI-generated code be reviewed and understood by the person submitting it:

Only submit a PR if you are able to debug and own the changes yourself – review all generated code to understand every detail

Once you’ve reviewed the changes and can own them yourself, you’re welcome to open a new PR.