src tarballs regenerate per rolling release; runtime provenance (built_from.release=spec22-chain) dangles

[ronaldtse]

Source tarballs regenerate with a new sha256 per rolling release; runtime provenance pointer dangles

Discovered while diagnosing a tebako-cli SDK-provisioning failure (cross-link: the tebako issue filed alongside this one).

Facts (verified 2026-08-27)

1. tfs-ruby-3.3.12-src.tar.gz has a different sha256 in every recent rolling release:

   release	sha256
   v0.2.21	38d41d860947…
   v0.2.22	db350614585a…
   v0.2.23	1149015b542f…
   v0.2.24	5d75e9151086…
   v0.2.25	1291a24e226e…
   v0.2.26/0.2.27	3adafef32b53…

2. tebako-runtime-ruby v0.16.11's manifest records its 3.3.12 build input as built_from.release = "spec22-chain", sha256 = a54f25657ae2… — which matches none of the above, and no release or tag named spec22-chain exists in this repo anymore.

Impact

• built_from.sources[].sha256 is unresolvable: no current release carries the digest the runtime was actually built from. Provenance auditing and any manifest-driven SDK resolution (the direction tebako wants per spec 00 law 10) are impossible.
• The CLI's SDK provisioning falls back to a hardcoded factory release that may carry a same-named tarball with different content than the runtime's actual build input.

Proposals (pick per factory ergonomics)

1. Make src tarballs content-stable: only regenerate when the patch set or ruby version actually changes (content-addressed skip if the tree hash is unchanged).
2. Make built_from.release an immutable, never-deleted release tag (whatever the daily monitor's GC policy is, the build-input release of any published runtime must survive).
3. Or strongest: attach the exact src tarball(s) used as assets on the tebako-runtime-ruby release itself, so the runtime release is self-contained provenance.