Leading-space checksum encoding is rejected

## Summary

`tar-framing` rejects a checksum field whose octal digits are preceded by a
space.

The [reproduction archive](https://gist.githubusercontent.com/zaniebot/88e6b0a9b7e9376324cd3357098e5e40/raw/6399c074efaa58541a60291ef1e243ddc5981b63/TC-C12.tar) is the libarchive compatibility fixture
`test_compat_perl_archive_tar.tar`. It is accepted by Rust `tar`, Tokio TAR,
CPython `tarfile`, Go `archive/tar`, and JavaScript `tar-stream`; all five expose
the same five-byte regular member named `file1`.

Tested with tar-codec revision
`1ac1199559a1b96f0f953ac99520ccc296503808`.

## Observed behavior

The checksum field is ` 11123\0 `. The stored value matches the header, but the
archive is rejected with:

```text
at byte 0: invalid tar checksum: stored None, computed 4691
```

## Expected behavior

Consider permitting leading space padding before checksum digits.

If rejecting this established encoding is intentional, it would be useful to
list it as a compatibility limitation.

## Impact

This is an interoperability issue, not an extraction vulnerability. It affects
real compatibility fixtures rather than only a synthetic edge case.

Start by reproducing the failure with the linked reproduction archive, `test_compat_perl_archive_tar.tar`, and the checksum field ` 11123\0 `. Trace the tar-codec checksum parsing entry point and verify that the fixture is accepted while the stored and computed checksum values remain consistent.

Written by the indexing model from the issue text.