bug: list command silently accepts path traversal entries in TAR archives

[bug-ops]

The list command displays ../escape.txt (a traversal entry) without any warning or error when the archive is a TAR. This is inconsistent with ZIP behavior where list raises PathTraversal error.

Reproduction

# TAR with ../escape.txt entry:
exarch list partial.tar
# Output: shows ../escape.txt as a normal entry, exit 0

# ZIP with ../escape.txt entry:
exarch list partial.zip
# Error: path traversal detected: ../escape.txt, exit 1

Root cause

inspection/list.rs: list_tar_entries uses entry.path() (raw tar-rs path, no validation):

let path = entry.path()...into_owned();  // no ../  check

ZIP uses entry.enclosed_name() which returns None for traversal paths, converted to PathTraversal error.

Impact

1. User confusion: list on a malicious TAR shows ../escape.txt as a valid path — no indication the archive is dangerous.
2. CLI conflict-check bypass: The extract command calls list_archive before extracting to detect conflicts. For TAR, this list call succeeds even with traversal entries, so the conflict check is effectively bypassed. Extraction starts, and traversal is only caught mid-extraction, leaving partial files on disk (see enhancement: extraction is not atomic — partial state left on disk when error occurs mid-archive #89).
3. Inconsistency: ZIP is safe, TAR is not.

Fix

In list_tar_entries, validate each path component for .. or null bytes, returning PathTraversal error (consistent with ZIP behavior). This also makes the CLI conflict pre-check effective for TAR archives with traversal entries.

[bug-ops]

Additional finding: verify correctly reports [CRITICAL] ../escape.txt: Path traversal detected (exit 1), while list shows ../escape.txt as a valid entry (exit 0). So the traversal-validation code already exists in inspection/verify.rs — list_tar_entries just needs to apply the same path component check.

[bug-ops]

Additional dimension found (S102): list also silently accepts absolute paths in TAR entries (/etc/evil.txt shown as-is, exit 0), not just .. traversal.

Reproduction:

import tarfile, io
buf = io.BytesIO()
with tarfile.open(fileobj=buf, mode='w:gz') as tf:
    info = tarfile.TarInfo(name='/etc/evil.txt')
    info.size = 5
    tf.addfile(info, io.BytesIO(b'world'))
buf.seek(0)
open('abs.tar.gz', 'wb').write(buf.read())

$ exarch list abs.tar.gz
/etc/evil.txt    ← shown with no warning, exit 0

Both verify and extract correctly reject it ([CRITICAL] Path traversal detected: /etc/evil.txt). The fix for list_tar_entries must check for both .. components and absolute paths — same validation that verify and extract already apply.

[bug-ops]

JSON output dimension (S107): list --json also returns "status": "success" with dangerous paths in the entries array — no warning, no flag on the dangerous entries.

$ exarch list --json archive.tar.gz
{
  "operation": "list",
  "status": "success",
  "data": {
    "total_entries": 4,
    "entries": [
      {"path": "readme.txt"},
      {"path": "/etc/evil.txt"},       ← absolute path, no flag
      {"path": "docs/guide.txt"},
      {"path": "../escape.txt"}        ← traversal, no flag
    ]
  }
}

A JSON consumer building a UI or automation on top of list would see a clean success response and have no indication that two of the four paths would cause extraction to fail. This makes the discrepancy between list and extract even more dangerous in programmatic use.

The fix for list_tar_entries should apply validation to each path and either:

1. Skip dangerous entries (match ZIP behavior, which uses enclosed_name() and returns PathTraversal error)
2. Or include a "warning" field on dangerous entries
   Option 1 is consistent with what verify and extract do.