Produce a software bill of materials and a build provenance attestation for every artifact

[iderex]

The target gate produces both, reported as Package (JPRM) / Generate SBOM
alongside its package build. A consumer of this core will be a client shipped to
other people's devices, so what went into it and where it was built are questions
somebody downstream will have to answer about their own product.

What this produces

A bill of materials generated from the resolved dependency graph rather than
written by hand, attached to every release artifact.

A signed provenance attestation produced by the build that made the artifact, so
that an artifact claiming to come from this repository can be checked against
that claim.

A verification command in the documentation that somebody downstream can run
against a downloaded artifact, since an attestation nobody can check is a file.

Done when

Every release artifact carries both, the verification command is documented and
proven to succeed on a real artifact and to fail on a modified one. Blocked on
#19, #94, and #103 for the licence set this bill of materials is read against.

[iderex]

The sentence in the body about the target gate is right that both halves exist
there and wrong about where they run, and the difference decides what the first
condition here can be asked to mean. Read at
76d27fdddb3e28e314708235b040d9bc6a0b688a on that repository.

git clone --depth 1 https://github.com/Flowfin/jellyfin-plugin-sso ssoclone
cd ssoclone && git rev-parse HEAD
76d27fdddb3e28e314708235b040d9bc6a0b688a
grep -n 'name: Build package\|attest-build-provenance\|name: Generate SBOM' .github/workflows/build.yml
42:    name: Build package
77:        uses: actions/attest-build-provenance@4d101475d8b20a2381f78447822ac1eab6504dd8 # v4.2.2
103:    name: Generate SBOM

They are two jobs rather than one, and the attestation is not reported under the
name the body quotes. Both are gated on the same input, which is false unless a
caller sets it:

grep -n 'if: ${{ inputs.attest }}' .github/workflows/build.yml
76:        if: ${{ inputs.attest }}
104:    if: ${{ inputs.attest }}
grep -n 'attest:' .github/workflows/dotnet.yml .github/workflows/publish.yml
.github/workflows/publish.yml:52:      attest: true

The release caller sets it and the other caller passes nothing, so the default
stands there. What that leaves on the default branch is a name with no work
behind it:

gh api repos/Flowfin/jellyfin-plugin-sso/commits/main/check-runs --jq '.check_runs[] | select(.name|test("Package")) | "\(.name)\t\(.status)\t\(.conclusion)"' | sort -u
Package (JPRM) / Build package	completed	success
Package (JPRM) / Generate SBOM	completed	skipped

So the run the body names as the model produced no bill of materials on the
commit a reader would compare against. Nothing about the target is missing; it is
on the release path and reachable only from there.

The part that reaches this issue rather than that description is why the two are
separate jobs, because the first condition here reads as though they were one
thing applied to every artifact. The reason is written in that gate's own
comments:

The CycloneDX SBOM runs in its OWN release-only job, DELIBERATELY WITHOUT the
signing scopes the build job holds. The SBOM generator installs a NuGet global
tool at run time; keeping it out of the job that carries id-token/attestations
write means a compromised tool can never reach the Sigstore signing identity or
mint a provenance attestation (SLSA L3 build-isolation). The SBOM is shipped as
a checksummed release asset (like the beta/JF12 legs), not attested - the
isolation is worth more than attesting the side-document.

Two things follow.

A bill of materials is itself a release artifact, and there it deliberately
carries no attestation. "Every release artifact carries both" read literally
therefore asks this board for the one thing that gate paid a job boundary to
refuse, and it would be satisfied by putting the generator back inside the job
holding the signing identity, which is the arrangement the isolation exists
against. Which of the two this repository wants is a decision rather than an
oversight, and taking it while a workflow is being written is taking it by
accident.

The generator is what forces the boundary rather than the document. The tool
there is installed at run time, so the job that produces the bill of materials
runs code that arrived during the run, and that is the thing kept away from the
signing scopes. Whether the same is true here is not knowable yet: it depends on
what produces a graph at all, which is #11, and on what may be in that graph,
which this issue already waits on #103 for.

Nothing here answers what this issue waits on, and I have changed no condition
and no scope. None of the above is a measurement of anything this repository
builds: there is no release artifact in this tree, so no verification command has
been run against one and the second half of the condition here is untested rather
than passing.