fix(archive): validate GNU tar metadata

[rustytrees]

Description

The tar pre-scan now reads GNU long-name and long-link records before validating the following entry. It checks the same effective name and link target that the extractor uses.

Regression tests cover an escaping long-link target, a hidden symlink name followed by an outside write, and safe GNU metadata.

Related Issue

Closes #854.

Notes for Reviewers

Verification completed:

• zig build test-one: 2,427 passed
• zig build test: 5,062 passed, 3 skipped
• Commit signature verified with git verify-commit

[indaco]

@rustytrees Thanks for the contribution! One small request: could you please instruct your agent to follow the PR template provided in the repository for PRs? It helps keep the PRs consistent and easier to review. Thanks!

[rustytrees]

I published a runnable PoC for the GNU metadata mismatch fixed here:

• h01-gnu-metadata source
• runner at signed commit bd0e2a4
• digest-pinned release archive

git clone https://github.com/rustytrees/malt-security-pocs.git
cd malt-security-pocs
git checkout bd0e2a4d088cc63c8a7ab1613e851d23808b5a4d
./scripts/run-poc.sh --malt /path/to/malt --expect vulnerable h01

The PoC combines GNU L and K records so preScanTarGz sees the benign ustar fields placeholder and safe, while Zig's iterator gives extraction the effective symlink name door and an absolute target outside MALT_PREFIX. A later door/escaped entry performs the outside-prefix write.

Exact efd2b99 reproduced the write through malt install with Malt status 0. The combined patched build containing this PR rejected extraction, installed no package, and left the canary absent. This matches the PR tests extractTarGz rejects an escaping GNU long-link target and extractTarGz rejects a write through a GNU long-named symlink.