Leading-space ordinary numeric metadata is rejected

## Summary

`tar-framing` rejects ordinary-header octal metadata when the digits are
preceded by a space.

The [reproduction archive](https://gist.githubusercontent.com/zaniebot/88e6b0a9b7e9376324cd3357098e5e40/raw/6399c074efaa58541a60291ef1e243ddc5981b63/TC-C14.tar) places a leading space in the `uid`
field. 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 eight-byte `uid` field is `[32, 48, 48, 48, 48, 48, 48, 0]`. The archive is
rejected with `invalid tar uid field` before the member is returned.

## Expected behavior

Consider accepting leading space padding before octal digits in ordinary
numeric metadata fields.

If leading-zero padding is intentionally required, it would be useful to list
the stricter grammar as a compatibility limitation.

## Impact

This is an interoperability issue, not an extraction vulnerability. The same
differential is observable in `mode`, `gid`, `mtime`, and `size` fields.

Start by reproducing the rejection with the linked TC-C14.tar archive using tar-codec revision 1ac1199559a1b96f0f953ac99520ccc296503808, then trace the parser for ordinary numeric metadata fields. Done means the archive's leading-space uid is accepted and the same behavior is covered for mode, gid, mtime, and size without weakening other validation.

Written by the indexing model from the issue text.