fix(importer): handle non-fixed-width multi-volume RAR volume naming

[javi11]

Problem

Multi-volume RAR sets numbered without consistent zero-padding — …part01.rar……part09.rar, then …part010.rar……part0NN.rar (literally part0 + the unpadded number) — failed to import and play. Example: a 259-volume, 27.2 GB stored REMUX imported with only 946 MB of segments (9 volumes) and failed at playback with:

[createUsenetReader] No segments to download
  start=0 end=27223903104 available_bytes=946944000 expected_file_size=27223903105

Root cause

The rardecode fork follows a multi-volume set by computing the next volume name at the first volume's digit width (nextNewVolName). After …part09.rar (2 digits) it asks for …part10.rar, but the real file is …part010.rar. This width mismatch broke the set in two places:

1. Volume following — UsenetFileSystem.Open missed …part10.rar → rardecode stopped at volume 9.
2. Part → segment mapping — convertAggregatedFilesToRarContent mapped rardecode's computed part.Path (…part10.rar) back to the NZB file via exact-name lookup, so even when all volumes were followed, only part01–part09 matched and the rest were dropped → import failed with no files were successfully processed.

Fix

• New leaf package internal/importer/rarname — SetKey / VolumeNumber / Scheme + regexes as the single source of truth. archive re-exports them and rar aliases archive.*. (A leaf package is required because archive → archive/iso → filesystem, so the helpers can't live in archive or rar without an import cycle.)
• UsenetFileSystem & DecryptingFileSystem — on an exact-name miss, Open/Stat resolve a volume by (set, scheme, volume-number), so …part10.rar → …part010.rar regardless of padding width.
• convertAggregatedFilesToRarContent + nested mapNestedFile* — resolve part.Path → source the same way via a generic partLocator[T], so every followed volume's segments are attached.
• Coverage guard in AnalyzeRarContentFromNzb — fail an import when followed volume bytes are < 80% of supplied volume bytes, surfacing truncated/incomplete sets at import time instead of at playback.

Tests

• Unit tests: rarname (width-independent parsing), the volume_index/partLocator resolvers (incl. cross-set collision), the truncation guard, and the segment mapping (TestConvertAggregatedFilesWidthMismatch).
• End-to-end import battery test TestImportBattery_RarWidthMismatchVolumeNaming, backed by a committed 14-volume fixture (part01…part09, part010…part014) generated by testdata/gen_fixtures.sh. Runs the full ProcessNzbFile pipeline over the in-memory fakepool and asserts full segment coverage.
• Verified RED without the fallback (reproduces no files were successfully processed) and GREEN with it. go test -race ./internal/importer/... passes; build + gofmt clean.

Reviewer notes

• The committed binary fixture (~212 KB) is generated by rar + a rename step in gen_fixtures.sh; CI needs no rar (fixtures are committed, loadManifest t.Skips if absent).
• Encryption was investigated and ruled out: the archive is -m0 stored, unencrypted; has_password=true (from the NZB <meta password>) is harmless and the Password.txt in such releases is a filename de-obfuscation password, not a RAR password.