tests/test_discs.py: size-based disc pinning assumes distinct sizes, and a real counter-example now exists

[bmxcode]

Context

`tests/test_discs.py` pins discs by exact byte size rather than filename, on the reasoning in `_pinned_disc()`'s docstring: "Sizes are distinct across all 79 images measured. Two files of exactly one size are far more likely a disc filed twice than a coincidence." When two files share a pinned size, `_pinned_disc` calls `pytest.fail` rather than guessing which one is meant.

What was found

While consolidating the local disc collection (folding a stray `sample-discs-test/` folder back into `sample-images/`, and filing a batch of new downloads), two files turned up that are exactly the same size — 399,077,376 bytes, the pinned `eiv-studio` size — but are not the same disc:

• `Producer Series Vol. 1 – Studio Essentials (E-MU E-IV CD-ROM).iso`
• `Producer Series Vol. 2 – More Studio Essentials.ISO`

Confirmed via SHA-256 that the two payloads are different:

```
4ce82b1a...5f4 Producer Series Vol. 1 – Studio Essentials (E-MU E-IV CD-ROM).iso
caeeebdb...2da Producer Series Vol. 2 – More Studio Essentials.ISO
```

So this isn't the "disc filed twice" case the size-pinning was written to catch — it's a genuine coincidence (both E-IV Producer Series CD-ROMs from the same publisher, almost certainly mastered to the same fixed image size). With both discs filed under `SAMPLERDISC_TEST_DISCS`, every run now fails `eiv-studio`'s two pinned tests:

```
Failed: eiv-studio: 2 images are exactly 399077376 bytes: Producer Series Vol. 1 – Studio Essentials (E-MU E-IV CD-ROM).iso, Producer Series Vol. 2 – More Studio Essentials.ISO
```

This is the correct behaviour for the case the code anticipated (refuse to guess), but it's now a permanent, expected failure rather than a transient one to fix and move past — the two discs are just going to keep colliding.

Possible directions (not prescribing one)

• A secondary disambiguator beyond size for the handful of pins that need it — e.g. a content hash of the first N bytes, computed only when a size collision is hit.
• An explicit "known collision" allowlist next to `_pinned_disc`, so a real coincidence like this one can be told apart from an actual "filed twice" mistake without silencing the check for everyone else.
• Leave it as manual triage (skip filing both, or set `SAMPLERDISC_TEST_DISCS` to exclude one) — cheapest, but relies on whoever hits it next rereading this issue.

Not fixing this now — filing so it doesn't get rediscovered as a mystery failure later. Details and the collision are documented in the (private, non-repo) disc inventory notes for reference.

[bmxcode]

Fixed by D21 (#40), which took this issue's first suggested direction — "a content hash of the first N bytes, computed only when a size collision is hit".

tests/test_discs.py now carries _HEAD_DIGEST, a SHA-256 of the image's first 1 MiB consulted only when two images share a pinned size, with an entry for eiv-studio. _pinned_disc still fails rather than guessing where a collision has no digest, so the check this issue was written to protect is intact.

Verified 2026-08-24 with both discs filed side by side — Producer Series Vol. 1 – Studio Essentials in active/archive-oldschoolscds/ and Producer Series Vol. 2 – More Studio Essentials in active/e-mu-eiv-series-factory-library/, still both exactly 399,077,376 bytes and still genuinely different discs:

PASSED tests/test_discs.py::test_emu3_discs_list_their_banks_and_samples[eiv-studio]
PASSED tests/test_discs.py::test_emu3_loops_are_decoded_without_disturbing_the_audio[eiv-studio]

The full collection sweep is 618 tests, all passing, with Vol. 2 in the set. The collision is real and permanent; the failure it used to cause is not.