Give the 12.0 package a release leg

[iderex]

The build packages both supported server lines and the release route publishes one of them. Read at:

git rev-parse origin/master
e941800b27ee2944bc0759cef29a403e4f98e00d

What the tree does today

One build run produces one artefact per line, each compiled for its line and carrying its own manifest:

gh api repos/Flowfin/jellyfin-plugin-metadata-sync/actions/runs/34004224900/artifacts --jq '.artifacts[] | "\(.name)\t\(.size_in_bytes) bytes"'
build-artifact	64764 bytes
build-artifact-jf12	64530 bytes

The release route reads the committed build.yaml and no other manifest. The gate step is named for that file, the framework it expects is a literal of the 10.11 line, and the other manifest is mentioned once, in the header that says the route does not read it:

git show origin/master:.github/workflows/publish.yaml | grep -n 'name: Check the tag and build.yaml agree\|EXPECTED_FRAMEWORK: '
94:      - name: Check the tag and build.yaml agree
99:          EXPECTED_FRAMEWORK: "net9.0"
259:          EXPECTED_FRAMEWORK: "net9.0"
309:          EXPECTED_FRAMEWORK: "net9.0"

git show origin/master:.github/workflows/publish.yaml | grep -c 'build-jf12.yaml'
1

Two pages say the same, and both were written as a gap rather than as a decision:

git show origin/master:docs/RELEASING.md | grep -n 'has no release leg'
18:package. The 12.0 package exists as a build artefact and has no release leg.

git show origin/master:docs/supported-servers.md | grep -n 'A second release leg is not written'
107:The 12.0 package has none. A second release leg is not written, so what exists

So an operator on the 12.0 line can pair, through the pairing plugin that carries both lines, and cannot install this plugin from any release. That is the state decision 4 in #1 was taken against. #9 built the two packages and closes on its four conditions; its notes named this as the next piece of work the issue implies, and it gets an issue of its own here so it is held rather than read as a gap nobody owns.

What has to be decided, and where the answer comes from

The tag has to select the manifest. The band table in docs/supported-servers.md gives each line a major version, 1 for the 10.11 line and 2 for the 12.0 line, and the second manifest already sits at the foot of its band:

git show origin/master:build-jf12.yaml | grep -n '^version:\|^targetAbi:'
29:version: "2.0.0.0"
30:targetAbi: "12.0.0.0"

So a tag's major already says which package it names, and a route that reads the manifest whose band the tag's major falls in needs no second tag grammar and no second workflow. That is the shape I would start from, and it is written here as the starting point rather than the decision: what this issue owes is the shape with its reason, in the pull request that lands it.

Two constraints stand whichever shape is taken. The route refuses to guess, which its header already says: a tag naming neither band's manifest is refused, never matched to whichever file was found. And the agreement #370 holds for the first package, the tag against the manifest against the assembly as one number, holds for the second in the same way, so ReleaseVersionAgreementTests reads the second leg as it reads the first.

Done when

• a tag inside the 12.0 band publishes the 12.0 package from build-jf12.yaml, and a tag inside the 10.11 band still publishes the 10.11 package from build.yaml, with the tag, the manifest and the assembly held to one number for whichever manifest the tag selects
• a tag naming neither band's manifest is refused before anything is published, and the refusal is proven by deleting it and watching the suite go red
• ReleaseVersionAgreementTests and ReleaseRouteTests hold the second leg the way they hold the first, with the near-misses done to the route itself and not only to fixtures
• docs/RELEASING.md, the header of publish.yaml and docs/supported-servers.md stop saying the 12.0 package has no release leg, from a reading of the route rather than by deleting the sentence
• the row for publish-jf12-stable.yml in docs/gate-parity.md says what this repository has instead

What this does not decide

Whether the catalogue on the hub board lists a 2.x release under the same entry as the 0.x ones, and what a server on the 12.0 line is offered when it does, is that board's tree and the reading docs/supported-servers.md already carries about how a server selects between two entries. channel-freshness.yml compares this repository's releases with the served file in both directions, so a 2.x release the catalogue does not carry is reported there and not here.