VSTD 1.2.0: bind SBOM evidence and prepare immutable GitHub releases

[TimeLordRaps]

Coordinate

VSTD 1.2.0 release-candidate supply-chain implementation and repository-setting evaluation. Existing exact-byte manifests, reproducible
builds, signatures, and GitHub artifact attestations remain authoritative for their named
properties.

Target

• Verify the current official GitHub mechanism and constraints for immutable releases
  before changing repository settings.
• Evaluate a Software Package Data Exchange (SPDX) or CycloneDX software bill of materials
  (SBOM) generated from the exact release commit and distributions.
• Determine how the SBOM digest should be bound beside existing release artifacts without
  making it self-referential.
• Specify additive correction behavior when released metadata is wrong.

Exit criteria

• Any mechanism is documented from current official behavior, not assumed.
• SBOM bytes and provenance are bound to the exact release coordinate.
• Existing manifests and attestations are complemented, never replaced or overstated.
• Immutability does not conceal the need for additive corrections or revocation evidence.

[TimeLordRaps]

Implemented and bounded in stacked pull request #27 at d941df4.

Evidence:

• Release builds now emit a deterministic CycloneDX 1.6 Software Bill of Materials (SBOM) whose subjects are the exact source ZIP, wheel, and source distribution by SHA-256 and byte size.
• The external manifest binds the SBOM digest without self-reference; regeneration and tamper tests fail closed.
• Release publication is draft-first: create the complete draft with assets, then publish. The SBOM is boundary-scanned and attested alongside existing evidence.
• The generated payload passed the official CycloneDX 1.6 JSON Schema locally; exact-commit distributions, manifest, wheel install, and reproducibility checks passed locally and in hosted run 33038825743.
• GitHub's official 2026-03-10 API reported enabled=false and enforced_by_owner=false for this repository on 2026-08-26. Existing releases v0.1.0 through v1.1.3 report immutable=false.

One intentionally sequenced repository-setting action remains: enable immutable releases only after #27's draft-first release workflow has landed on the protected release path. Enabling it before that change lands could prevent the current direct-publish workflow from attaching assets. This is a safety dependency, not a substituted or abandoned deliverable. Additive correction/revocation behavior is documented.