core module has almost no test coverage #2

Context

The fork's testing effort — substantial, and carefully documented in TESTING.md — targets
driver and web-ui. The core module was left out:

core's only test is BytesUtilsCharacterizationTest, a characterization of the endianness
helpers.

It is the least covered module, and it is the one that produces the bytes written to the card.
It holds the readers and writers for all three pack formats (binary, archive, fs), plus
XXTEACipher, PackAssetsCompression, VorbisEncoder, AudioConversion and
ImageConversion. The hardening work done on driver establishes that the index and its
installation are correct — but nothing currently establishes that the content written into
.content/ faithfully represents the source pack.

The risk is not hypothetical, since driver builds on these classes: silent corruption
introduced during conversion would pass every existing specification.

Description

Establish coverage for core, starting with the property that matters most and costs least to
write: the round trip. A pack synthesised in code, written and then read back, must yield
an equivalent model — for each format, and for each cross-format path the library offers.

Follow the distinction TESTING.md already sets out: characterize what the code does today,
including where it is wrong, then convert to specifications as defects are fixed.

Affected files

• core/src/test/java/studio/core/v1/ — most of the work, to be created
• core/src/main/java/studio/core/v1/reader/{binary,archive,fs}/ — under test
• core/src/main/java/studio/core/v1/writer/{binary,archive,fs}/ — under test
• core/src/main/java/studio/core/v1/utils/XXTEACipher.java — test vectors
• core/src/main/java/studio/core/v1/utils/PackAssetsCompression.java — under test
• possibly a shared PackFixtures, along the lines of DriverTestSupport

Implementation plan

1. A fixture builder: a parameterisable synthetic StoryPack (node count, assets present or
   absent, enriched metadata or not). No device data committed, as driver already does.
2. Per-format round trip: write → read → structural comparison of the model.
3. Cross-format round trip: binary → archive → binary, and the other paths exposed by
   LibraryService. This is what a user actually exercises.
4. XXTEACipher: known vectors, plus the decipher(cipher(x)) == x property.
5. PackAssetsCompression: compress then decompress, and hasCompressedAssets on a mixed
   pack.
6. Failure paths: truncated file, invalid magic number, asset referenced but missing.
   Characterize what happens today — several of these likely produce an unhelpful exception,
   or a partial pack.
7. Extend the "Coverage map" table in TESTING.md.

Acceptance criteria

• Round trip covered for all three formats
• Cross-format conversions covered in both directions
• XXTEACipher covered by vectors and by its involution property
• Failure paths characterized, with KNOWN GAP marked as such
• No device data or third-party content committed
• TESTING.md updated (coverage map and counts)
• mvn -Dskip.installnodeyarn=true -Dskip.yarn=true test green on Linux and Windows

Complexity

L — the work splits cleanly per format and can land across several PRs.