Full-width octal numeric field without a terminator

## Summary

`tar-framing` rejects a TAR header when an octal numeric field occupies its
full fixed-width slot without a trailing NUL or space.

The [reproduction archive](https://gist.githubusercontent.com/zaniebot/88e6b0a9b7e9376324cd3357098e5e40/raw/6399c074efaa58541a60291ef1e243ddc5981b63/TC-C10.tar) is accepted by other common TAR readers,
including Rust `tar`, Tokio TAR, CPython `tarfile`, Go `archive/tar`, and
JavaScript `tar-stream`. They all expose the same member and payload.

Tested with tar-codec revision
`1ac1199559a1b96f0f953ac99520ccc296503808`.

## Observed behavior

The archive is rejected with:

```text
at byte 0: invalid tar gid field: found [49, 48, 48, 48, 48, 48, 48, 48]
```

Those bytes are the ASCII octal value `10000000`. The value fills the complete
eight-byte `gid` field, leaving no byte for a NUL or space terminator.

## Expected behavior

Consider accepting a fixed-width numeric field when every byte is a valid octal
digit and the decoded value fits the destination type, even if the field has no
explicit terminator.

If requiring a terminator is intentional, it would be useful to document this
as a compatibility limitation.

## Impact

This is an interoperability issue rather than a payload-framing or extraction
vulnerability. Archives using full-width numeric identifiers can be rejected
before any member is returned.

No repository file or test is named. Start by reproducing the failure with the linked TC-C10.tar archive and tracing tar-framing's gid-field parsing at the tested revision. Done means either accepting a full-width, valid octal value that fits the destination type, with regression coverage, or documenting the intentional compatibility limitation.

Written by the indexing model from the issue text.