fix: decompressing with --format overwrites the input file

[VXNCXNX]

What's broken

ouch decompress <file> --format <fmt> derives the output name from the input's full file name, so the two are equal. With --here (or --dir .) the input is truncated to zero bytes and the run then fails, so the archive is gone.

Fixes #442

Repro

$ echo "hello world data" > file
$ ouch compress file file.zst.zst.zst
$ ls -l file.zst.zst.zst
44 file.zst.zst.zst

$ ouch decompress file.zst.zst.zst --format zst --here -y
[ERROR] Failed to decompress file.zst.zst.zst
 - incomplete frame
$ ls -l file.zst.zst.zst
0 file.zst.zst.zst        <- input destroyed

after:
[INFO] Input file size: 44 B / Output file size: 35 B
44 file.zst.zst.zst       <- intact, md5 unchanged
35 file.zst.zst           <- output

The fix

Strip as many trailing known extensions as --format names, so file.zst.zst.zst --format zst writes file.zst.zst. A name with no known extension falls back to <name>-output rather than colliding.

Verification

decompress_with_format_flag_does_not_overwrite_input asserts the input bytes are unchanged and the derived output exists. Reverting the name derivation fails it: the input reads back as empty.

I also checked the paths this could have disturbed, comparing binaries built before and after: archive extraction with --format, stdin input, and plain .gz decompression without --format all behave identically.

Full suite passes. cargo fmt --check and cargo clippy --all-targets -- -D warnings clean. I built with bzip3 off, since libbzip3-sys will not compile here (missing stddef.h), and nothing in the diff touches it.