Arbitrary file write via path traversal in unpackToDir

Summary

# Arbitrary file write via path traversal in unpackToDir

`Codec.Archive.unpackToDir` extracts a tar (or other archive supported by the libarchive C library) from a `ByteString` into a directory. `unpackToDirLazy` is the streaming variant; both funnel through the same internal `unpackEntriesFp` routine.

`unpackEntriesFp` joined each entry's name onto the destination directory with `System.FilePath.(</>)` without validating the name. Entry names starting with `..` sequences therefore escape the destination: `fp </> "../../../../etc/x"` resolves outside the extraction root. The joined path is written back into the archive entry (`archiveEntrySetPathname`) and handed to libarchive's `archive_read_extract` with no `ARCHIVE_EXTRACT_SECURE_*` flags, so neither the Haskell layer nor the C library rejects the traversal. The `..` check is not limited to tar archives: any format whose entry names libarchive reports verbatim is affected. Extraction result codes were also discarded, so write failures could pass unnoticed.

An attacker who can supply an archive to a service that extracts it with these APIs gains an arbitrary file write with the privileges of the extracting process. A demonstrated escalation (verified in a container): an archive with member `../../../../etc/profile.d/zz-poc-zipslip.sh` plants a shell script sourced by every subsequent login shell, converting the file write into code execution when any user logs in.

The reported traversal is fixed in libarchive-3.0.6.0, which fails with `ArchiveFatal` when an entry path begins with `..` (commit `325a2296379905557de1fa21b28d86f34bab2441`).

Users should upgrade to libarchive-3.0.6.0 or later. If pinned to an older version, validate entry names before extraction (reject absolute paths and any path containing a `..` component) or extract inside a sandboxed directory.

External vulnerability reported by Akash Sebastian (justabughunter).