Fuzz the parsers, and replay the seed corpus inside the gating build

[iderex]

The target gate does something with fuzzing worth copying exactly. The
coverage-guided run is scheduled and non-gating, because it is slow. The seed
corpus is replayed inside the gating build, because that is fast, and it catches
the case where a change makes a known-hostile input throw something the code does
not name.

The two are different questions. One looks for new inputs. The other proves the
inputs already known to be hostile are still handled.

This repository has more parser surface than the target does, because it decodes
images from a network as well as parsing server responses, and an image decoder
is the most attacked thing here.

What this produces

Fuzz targets over every parser the core exposes to server-supplied bytes: the
response decoding, the address parsing in #28, and the image format handling in
#55.

A committed seed corpus per target, including every input that has ever caused a
defect.

A replay of the whole corpus inside the gating build, failing on any unnamed
exception. The target list derived from the corpus directories rather than
written in the workflow, so a target added by having a corpus cannot be silently
uncovered by a list nobody updated. An empty corpus directory fails rather than
passing quietly, since replaying nothing proves nothing.

The harness compiled by the gating build even though the coverage-guided run is
scheduled, so a rename that breaks the harness reddens the pull request that
caused it rather than a scheduled run days later.

Done when

Each target has a corpus with at least one seed, the gating build replays all of
them, an empty corpus reddens the build, and a deliberately unhandled input in a
seed reddens it. Blocked on #28, #37, #55 and #101.

[iderex]

The target list here names three parsers, and two more have landed in records written after this issue was. Both sit on bytes that docs/decisions/0101-what-the-core-trusts.md calls untrusted, and neither is reachable through any of the three named. Read at e5a513c23f9bc6a0ddedc7b52bb299ae5d0cee05.

The rule the list has to satisfy is 0101's, and it is wider than a response body:

git show origin/main:docs/decisions/0101-what-the-core-trusts.md | sed -n '11,17p'
The core trusts two parties and each for one narrow thing, the client that hosts
it for the seams it supplies and for passing on what the operator typed, and the
operator for the single decision of which server may be talked to; every byte
that arrived over a network and every byte read back out of a store is untrusted
input whatever its origin, the device is treated as shared with another person,
losable and holding a second account, and everything else the core meets is
untrusted by default rather than by omission.

The first surface is a second thing arriving over the network, on its own connection rather than as a reply to a request the core made. docs/decisions/0116-learning-that-something-cached-has-changed.md decides the core listens for change notifications, and states what arrives on it:

git show origin/main:docs/decisions/0116-learning-that-something-cached-has-changed.md | sed -n '22,30p'
Two message kinds on the session connection, read at
`ae8723026d97b6d0f926638803edef338919b794` in the public server repository:

    $ git clone https://github.com/jellyfin/jellyfin
    $ J=ae8723026d97b6d0f926638803edef338919b794
    $ git -C jellyfin grep -n "LibraryChanged\|UserDataChanged" "$J" \
        -- MediaBrowser.Model/Session/SessionMessageType.cs | sed "s/^$J://"
    MediaBrowser.Model/Session/SessionMessageType.cs:13:        UserDataChanged,
    MediaBrowser.Model/Session/SessionMessageType.cs:22:        LibraryChanged,

git show origin/main:docs/decisions/0116-learning-that-something-cached-has-changed.md | sed -n '35,42p'
    $ git -C jellyfin show "$J":MediaBrowser.Model/Entities/LibraryUpdateInfo.cs \
        | grep -n "public string\[\]"
    29:        public string[] FoldersAddedTo { get; set; }
    35:        public string[] FoldersRemovedFrom { get; set; }
    41:        public string[] ItemsAdded { get; set; }
    47:        public string[] ItemsRemoved { get; set; }
    53:        public string[] ItemsUpdated { get; set; }
    55:        public string[] CollectionFolders { get; set; }

That is six arrays of server-supplied identifiers whose length nothing here bounds, read on a connection that is held open rather than opened per call, and what the core does with them is invalidate entries and shorten freshness. A seed corpus for the response decoding does not reach it, because the framing and the message kinds are its own.

The second surface is the one 0101's other clause is about. docs/decisions/0105-an-entry-this-version-did-not-write.md puts a parser of the core's own on every byte that comes back out of a client-supplied store:

git show origin/main:docs/decisions/0105-an-entry-this-version-did-not-write.md | sed -n '11,17p'
Everything the core writes through the store in 0040 is wrapped in a small
envelope of the core's own carrying a format version, the kind of the payload,
the payload's length and a digest over it, and an entry whose envelope does not
parse, whose version is not the one this build writes, or whose length or digest
does not match what was read back is dropped where it was found and treated as
absent, without being read, without touching any neighbour, and with the drop
reported through 0100 rather than performed in silence.

A declared length and a digest read out of the same bytes they describe is the shape a fuzz target exists for, and 0101 states the threat model that makes it worth the seat: the device is shared, losable and holding a second account, so whoever can write to the store chooses those bytes. This one has a further property the other targets do not, which is that the record already names four distinct rejections, so a corpus can be built to reach each of them rather than only to avoid a crash.

Both of these bear on the condition rather than only on the body. Deriving the target list from the corpus directories, which is the right shape and the reason it is in this issue, protects against a list nobody updated. It does not protect against a target nobody created, because a target that was never thought of has no directory and the empty-directory rule has nothing to fail on. So the two above have to be named where somebody building the targets will read them, and the blocker list is where that would otherwise have happened: #116 and #105 are not in it, and the three parsers that are named all predate them.

I have changed no condition and no scope.