[rudra337-lgtm]

gh-159435: Fix tarfile offsets after PAX headers and GNU long names

Fixes gh-159435.

When a PAX extended header supplies a size record and is followed by a GNU
long-name header, TarInfo._proc_pax() calculated the next offset from
next.offset. GNU long-name processing reuses that field for the special
header, so the member header could be read again, causing duplicate members or
skipped members.

Capture next.offset_data before processing GNU sparse information and use it
as the base for the PAX size offset calculation. This preserves the existing
GNU sparse 1.0 behavior while fixing the long-name case.

The change includes a regression test and a Library NEWS entry.

Tests

• A stdlib-only reproduction against the patched Lib/tarfile.py passes for the
  PAX-size/GNU-long-name case and the existing GNU sparse PAX-size scenario.
• python -m py_compile Lib/tarfile.py Lib/test/test_tarfile.py
• git diff --check
• The native CPython test runner was not available on this host: only Python
  3.12 is installed, while current CPython main requires newer syntax/runtime
  features.

AI assistance: OmniRush was used for investigation and implementation. The
contributor is responsible for reviewing and maintaining this change.

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[haampie]

This is correct, confirmed it with the tar-minefield test suite case F10: https://stoppels.ch/tar/F10.html. It does not affect the outcome of any of the other 80+ test cases.