Publish the artifacts covered by release-source attestations

[forkwright]

Finding

The release-please workflow creates a custom source archive and CycloneDX SBOM, attests both, and then discards both files. Neither is uploaded as a workflow artifact or release asset. The automatically generated GitHub source archives are byte-distinct artifacts, so release consumers cannot obtain the subjects covered by these attestations.

Evidence

• .github/workflows/release-please.yml:50-57 creates harmonia-${TAG_NAME}.tar.gz with git archive.
• .github/workflows/release-please.yml:59-66 generates its SBOM with both upload-artifact: false and upload-release-assets: false.
• .github/workflows/release-please.yml:68-77 attests the custom archive and binds the SBOM to it, but contains no upload step.
• The live v0.1.14 release contains platform binaries, their SBOMs, checksums, and attestation bundles; it does not contain the custom source archive or source SBOM. GitHub's autogenerated “Source code” downloads are not the git archive file attested by this job.
• This is distinct from release-please: use an App/PAT token so releases merge on CI and auto-build assets (no admin, no manual dispatch) #564, which records the accepted manual release trigger; the defect is the subject/release artifact mismatch after the job runs.

Why this matters

The workflow can report successful source provenance and SBOM attestation without providing any releasable artifact to which a user can apply them. This creates assurance theater at the supply-chain boundary: the signed claim exists, but its exact subject is unavailable.

Desired correction

Upload the exact custom source archive and its SBOM to the GitHub release, with stable names and checksums, or attest the exact source artifact that the release actually publishes. Add a post-release gate that enumerates every attestation subject digest and proves a byte-identical downloadable release asset exists for it.