chore(deps)!: arrow 55 -> 59

[anoop-narang]

Summary

Moves the three optional arrow pins from 55 to 59. Two lines of dependency change and a CHANGELOG note — no source changes were needed.

arrow-ipc     = { version = "59", optional = true }
arrow-array   = { version = "59", optional = true }
arrow-schema  = { version = "59", optional = true }

Why this is breaking, and for whom

ArrowResult exposes RecordBatch and SchemaRef in its public API, so arrow's major version is effectively part of this crate's surface. A caller using the arrow feature has to move to arrow 59 in step — arrow types from two different majors are distinct types and will not compile together, with an error along the lines of:

note: two different versions of crate `arrow_schema` are being used; two types
      coming from two different versions of the same crate are different types
      even if they look the same

Callers not using the arrow feature are unaffected.

Why do it

arrow 55 is four majors behind current. Nothing is broken by the gap today — a consumer decoding Arrow IPC on 55 and a producer writing it on a later major render the same values identically, as far as I could observe. The point is that nothing pins them together: how a nested value is rendered can change across an arrow major, and a divergence introduced that way would show up as wrong output rather than as a build failure. Staying current shrinks that window.

Verification

• cargo build --all-features — clean, no source changes required
• cargo test --all-features — all tests pass
• Cargo.lock resolves arrow-array to 59.3.0

Also exercised end to end from a downstream consumer built against this branch via [patch.crates-io]: it compiled with its own arrow at 59, its full suite passed, and rendering of nested lists, structs, maps, decimals, binary, durations, dates, named-timezone timestamps and non-finite floats was byte-identical to the same values fetched as JSON from the API — 12 of 12 cases, checked against both arrow 55 and 59 on the consumer side.

Note for reviewers

cargo fmt --check and cargo clippy -D warnings are already failing on main under rustc 1.92 (8 clippy errors, several fmt diffs), in files this PR does not touch. Confirmed against an unmodified origin/main worktree, and this branch adds none: the clippy error set is identical, 8 before and 8 after. Left alone rather than folded in, since reformatting unrelated files would bury a two-line dependency change.

[claude]

Reviewed the dependency bump and the arrow call sites in src/arrow.rs. The used API surface (StreamReader::try_new, StreamReader::schema, RecordBatch, SchemaRef, arrow_schema::ArrowError) is unchanged across arrow 55 to 59, so no source change is expected. The crate declares no rust-version, so there is no MSRV field to update, and no Cargo.lock is committed. The CHANGELOG entry lands under ## [Unreleased], which matches the process in RELEASING.md; the release preparer must pick minor for this breaking change.

Build and test checks were still queued or in progress at review time, so this approval does not assert that they passed.

[claude]

Prior super nit is addressed: README.md:211-213 now names arrow 59 next to the dependency snippet. No further findings.