Arbitrary file write via path traversal in unpackToDir

# 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).