Wholly-space ordinary numeric metadata is rejected

## Summary

`tar-framing` rejects an ordinary-header numeric metadata field containing only
spaces.

The [reproduction archive](https://gist.githubusercontent.com/zaniebot/88e6b0a9b7e9376324cd3357098e5e40/raw/6399c074efaa58541a60291ef1e243ddc5981b63/TC-C15.tar) uses eight spaces for `uid`. 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 archive is rejected with:

```text
at byte 0: invalid tar uid field: found [32, 32, 32, 32, 32, 32, 32, 32]
```

## Expected behavior

Consider treating a wholly-space ordinary metadata field as absent, analogous
to the existing compatibility treatment for wholly-NUL fields.

If the distinction is intentional, it would be useful to document it.

## Impact

This is an interoperability issue, not an extraction vulnerability. The same
five-peer differential is observable for `mode`, `gid`, and `mtime`.

Start by reproducing the rejection with the linked TC-C15.tar archive and trace the ordinary-header numeric metadata parsing that reports the invalid uid field. Compare the existing wholly-NUL compatibility handling with wholly-space fields across uid, mode, gid, and mtime. Done means the archive is accepted consistently with the cited tar implementations, with regression coverage for the affected metadata fields.

Written by the indexing model from the issue text.