Record one response set from a Jellyfin 12.0.0 server, scrubbed to the synthetic values

[iderex]

Contributes to #104. It does not close it: the comparison in the harness is what closes that issue, and this gives it the first recording to compare against.

What changed

tests/recorded/jellyfin-12.0.0/ holds sixteen responses from a Jellyfin 12.0.0 server, one file per capability of 0272 that has a request to make, and RECORDED.md beside them: what each file shows, which capabilities have no request to record and why, and what was scrubbed in the order tests/recorded/README.md gives. The server was run for the purpose in a container on this machine, with a library of three two-second black videos generated by its own ffmpeg, so the item routes answer with items rather than empty lists and nothing in the recording was made by a person.

Each file is an envelope: capability, method, path, status, the three headers kept, the request body where the call had one, and body as parsed JSON or body_bytes with body_content_type where the answer was image bytes or empty. A comparison of shape needs the status and the content type as much as the fields.

The failure it prevents

A fake server whose every answer was written by hand is measuring the core against a guess, and #104 says what that costs: a field the real server dropped is right in the fixture and wrong on the wire, and the first report comes from somebody running it. A recording from a real server of a supported line is what the comparison reads, and the version it was taken against is written beside it.

Evidence

The scrub check over the tracked subject, run at this head before the commit:

$ bash .github/fixture-scrub/fixture-scrub.sh check
Every rule above was applied to its subject and refused nothing.

What the scrub did, counted while it ran: twenty-four distinct server-supplied identifiers in the raw recording, sixteen synthetic values available, so the first sixteen by appearance got one each and the last eight, image tags and blur-hash keys, share the sixteenth; the token removed from every envelope; the address https://server.invalid; the account name a-synthetic-user; the device identity synthetic from the first request. The raw recording never entered any tree.

The two commands CONTRIBUTING.md names before a push were run in this worktree and are pasted in the first comment below once they finish, because they take minutes and the check above is the leg this change is about.

What this does not cover

The comparison itself, the harness case that reads these files, and a recording from the 10.11 line, which is #88 and needs a server of that line. The eight shared identifiers are a bound a reader of an image tag has to know, and RECORDED.md says it where the files are.

Nobody other than me has read this change.

[iderex]

The two commands before a push, run in the worktree at this head with a target directory of its own:

$ cargo build --locked --all-targets
build rc=0
$ cargo test --locked
7 test result lines, every one of them ok, 0 failed
test rc=0

[iderex]

Closed in favour of #503, which carries the same recording scrubbed once more. Three things were wrong here, each a reason on its own: the files kept the server's timing header while RECORDED.md said three headers were kept; the sixteen synthetic identifiers were allotted by order of appearance, so the two episodes and the play session shared one value and the set could not show that next-up returned a different episode from the one marked; and it landed without the -text rule and the byte assertion that tests/recorded/README.md says the first recording lands with. The raw recording was scrubbed again outside any tree, so nothing here was edited in place.