fix: FreeSegments end calculation when crossing 2 GB boundary

[ariostas]

This PR fixes #1620. It turned out that #1601 caused an issue where self._data.end was set expecting the file to stay below 2GB, but then when writing it would realize it needed to switch to using a big file pointer, so there was a mismatch. The required_end takes into account whether it will have to be extended into a big file.

AI disclosure: I used assistance from Gemini for this PR, but I fully verified the changes and the logic.

[Copilot]

Pull request overview

Fixes a regression in the ROOT writer’s FreeSegments bookkeeping when the file grows past the 2 GB “big file” boundary, preventing an at_end assertion failure during large extend() writes.

Changes:

• Add FreeSegmentsData.required_end(...) to compute the correct logical end-of-file while accounting for small vs big TFree record sizing.
• Update FreeSegments.allocate(...) and FreeSegments.release(...) to use required_end(...) instead of deriving end from potentially mismatched cached/allocation-derived sizes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[codecov]

Codecov Report

❌ Patch coverage is 90.90909% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.76%. Comparing base (f4daa7a) to head (c78a813).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/uproot/writing/_cascade.py	90.90%	1 Missing and 1 partial ⚠️

Additional details and impacted files

Files with missing lines	Coverage Δ
src/uproot/writing/_cascade.py	86.77% <90.90%> (+0.45%)	⬆️

[ianna]

@ariostas - Great! Thanks for fixing it. The coverage target is high - which is the only thing that is not green. I'll merge it. Thanks.