Leading-NUL ordinary numeric metadata is rejected

[zaniebot]

Summary

tar-framing rejects ordinary-header octal metadata when NUL padding appears
before the digits.

The reproduction archive places a leading NUL 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 [0, 48, 48, 48, 48, 48, 48, 0]. The archive is
rejected with invalid tar uid field before the member is returned.

Expected behavior

Consider permitting leading NUL padding before octal digits in ordinary
numeric metadata fields.

If a leading NUL intentionally terminates the field immediately, it would be
useful to document the compatibility difference.

Impact

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

[woodruffw]

This is somewhat similar to #52. I'm pretty sure it's incorrect per pax, but it's marginal.