PAX overrides do not suppress validation of raw numeric fields

## Summary

`tar-framing` rejects an archive when a valid local PAX numeric override is
paired with a malformed value in the corresponding raw USTAR field.

The [reproduction archive](https://gist.githubusercontent.com/zaniebot/88e6b0a9b7e9376324cd3357098e5e40/raw/pax-override-invalid-raw-uid.tar)
contains `uid=42` in its local PAX header and `NOTOCTAL` in the following raw
USTAR `uid` field. Rust `tar`, Tokio TAR, and JavaScript `tar-stream` accept the
archive and return the member; tar-codec, CPython `tarfile`, and Go
`archive/tar` reject it.

Tested with tar-codec revision
`1ac1199559a1b96f0f953ac99520ccc296503808`.

## Observed behavior

The archive is rejected before the member is returned:

```text
at byte 1024: invalid tar uid field: found [78, 79, 84, 79, 67, 84, 65, 76]
```

The same behavior occurs when valid local PAX `gid` and `mtime` records
override malformed raw `gid` and `mtime` fields.

## Expected behavior

Consider applying the PAX override without validating the superseded raw USTAR
field. POSIX specifies that an extended-header value overrides the
corresponding USTAR field and that the contents of the overridden field are
ignored.

If validating superseded fallback fields is intentional hardening, it would be
useful to document the compatibility difference.

## Impact

This is an interoperability issue rather than an extraction vulnerability.
Conforming PAX metadata can supply the effective owner or timestamp, but the
archive is rejected because an otherwise-unused fallback field cannot be
decoded.

Start by reproducing the issue with the linked archive and inspect how local PAX values and raw USTAR numeric fields are parsed. Done means valid local uid, gid, and mtime overrides allow the member to be returned despite malformed superseded fields, with regression coverage for these cases.

Written by the indexing model from the issue text.