Positive PAX numbers reject a leading plus sign

## Summary

`tar-framing` rejects a leading plus sign on positive PAX numeric values.

The [reproduction archive](https://gist.githubusercontent.com/zaniebot/88e6b0a9b7e9376324cd3357098e5e40/raw/6399c074efaa58541a60291ef1e243ddc5981b63/TC-C20.tar) contains `uid=+1`. It is accepted by
Rust `tar`, Tokio TAR, CPython `tarfile`, Go `archive/tar`, and JavaScript
`tar-stream`; all five expose the same empty regular member named `file`.

Tested with tar-codec revision
`1ac1199559a1b96f0f953ac99520ccc296503808`.

## Observed behavior

The PAX extension is rejected with:

```text
at byte 0: invalid pax uid value: "+1"
```

The same rejection occurs for leading-plus `gid`, `size`, and timestamp values.

## Expected behavior

Consider accepting an optional leading `+` on otherwise valid positive decimal
PAX numbers.

If unsigned values intentionally require digits only, it would be useful to
document this compatibility restriction.

## Impact

This is an interoperability issue, not an extraction vulnerability. The parser
rejects the archive before returning the member.

Start by reproducing the rejection with the linked archive and inspect the PAX numeric-value parsing in tar-framing. Check how uid, gid, size, and timestamp values are validated, then add coverage for the reported leading-plus cases; done means the archive is accepted while invalid numeric values remain rejected.

Written by the indexing model from the issue text.