Adding .tar.xz in-place extraction support to hatchzip.

## Problem

`.tar.xz` is common for datasets and is currently refused before extraction (see the Formats section of the README and [docs/formats.md](github.com/xevrion/hatchzip/... The TODO lists it as requested after launch, and CONTRIBUTING says a new format starts with an issue describing the approach so the crash-safety argument is settled before code. This is that approach.

## Proposed solution

xz fits in-place extraction even better than gzip, because every xz block decodes on its own: a block starts with a fresh LZMA2 state and needs no window carried from the previous block, and the index before the stream footer lists each block's compressed and uncompressed size, so block boundaries are known without decoding. The multithreaded `xz` (the 5.8.x default) writes many blocks. Measured on this machine, `xz -6` on a 66.7 MB tar produced one stream of 3 blocks with CRC64, each block start a free resume point. At 24 MiB granularity that is far below the 256 MiB step, so space frees continuously and, unlike the `.tar.gz` path, the journal carries no decoder window at all: a point is just (block start offset, tar offset, tar parser position).

Design, mirroring the existing compressed-tar path:

- Nothing is trusted before a full scan: parse the stream header, every block header, the index and the footer, check the index records against the walk, then decode the whole stream once verifying every block's check. A damaged archive is refused un...