Name the entry tar could not write, and two CLI answers that were wrong

[otsobide]

Fixes #93, #67 and #75. Three small ones, all about what the tool tells you.

#93 — tar did not say which entry failed

Issue #64 asked a write failure to name the entry at fault. zip and 7z do. tar has two write paths, and the one an archive with nothing renamed takes, which on Unix is nearly every archive, still answered in the dependency's words.

before: failed to unpack `/…/out-tar/a.txt/b.txt`
after:  cannot write entry "a.txt/b.txt" to /…/out-tar/a.txt/b.txt: Not a directory (os error 20)
zip:    cannot write entry "a.txt/b.txt" to /…/out-zip/a.txt/b.txt: File exists (os error 17)

unpack_in itself is untouched: it is the traversal guard tar has always used, and its canonicalizing containment check is what stops a write from following a symlink already in the output directory. Only its error is dressed.

That error needs unwrapping first, because it is a stack of wrappers each adding the destination again:

[0] failed to unpack `/…/out/a.txt/b.txt`
[1] failed to unpack `a.txt/b.txt` into `/…/out/a.txt/b.txt`
[2] Not a directory (os error 20)

Only the last says what went wrong. Using level 0 inside an Entry, which names the destination itself, printed the path three times.

The test that should have caught this passed for the wrong reason. It asserted message.contains("a.txt/b.txt"), which tar satisfied because the entry name is a substring of the destination path, so the guarantee was never checked at all. It now requires the name quoted as an entry.

#67 — it answered with a path you never typed

$ collapse compress ./sub/a.txt -f zip
before: Created /Users/…/scratch/misc.A4Z7/sub/a.txt.zip
after:  Created ./sub/a.txt.zip

The canonicalization is there for good reasons and stays: ., .. and a trailing slash need to resolve to something with a usable name, and an output aliasing the source can only be caught against a resolved path. Both spellings are kept now, and each is used where it belongs. The arcname deliberately keeps taking the resolved name, since that is what is stored inside the archive.

A source with no name of its own falls back to the resolved path, which is also what keeps a directory's archive beside it rather than inside it, where the guards would then refuse it.

#75 — -f and -o could contradict each other in silence

$ collapse compress notes.txt -f tar -o mixed.zip
Created mixed.zip
$ collapse extract mixed.zip -o out
error: Could not find EOCD

Refused now, before anything is read or written:

error: --format says tar but mixed.zip ends in .zip, which is a different format. Drop one of the two.

A warning was the other candidate and is worse: it goes to a terminal nobody reads in a script, and what is left is still a broken file with a misleading name.

An extension naming no known format is deliberately not a contradiction. -o backup.bin -f 7z is a choice, and a guard that refused it would be overreaching.

Tests

Seven new, each checked against the unfixed code:

mutation	tests that fail
tar back to the dependency's wrapper	1
#67 reverted, reports the resolved path	2
#75 reverted, --format wins in silence	1
#75 over-refusing, unknown extension breaks -f	2

One desktop assertion moves with #93: it pinned the old tar message, and the new one is strictly better, so it now requires the entry named and the real cause, and fails if the dependency's wrapper leaks through again.

620 Rust tests and 116 Vitest, 505 offline. architecture.md's compression flow updated, since steps 1 to 3 described the old behaviour.