registry: the tpkg-registry.yaml mirror, rendered from release shards

[ronaldtse]

What

The factory gains its tpkg-registry.yaml mirror (spec 04 §2) — the python runtime's zero-config resolution channel (spec 05 §2 channel 3), closing the gap that made every python payload require a runtimes: {python: {source: …}} config pin.

• tools/registry_update.rb — the shard-derived renderer (the openjdk port of tebako-runtime-ruby#161, adapted): reads a release's per-package .manifest.json shards (ground truth, never a job's local knowledge), renders one python runtime entry with engine: python from day one (MINOR 1 — an engine-less entry is invisible to kind: runtime edges), additive merge, withdrawal-preserving, default: tracking the newest live line.
• Composite <python>-<tebako> version keys (the ruby factory's grammar): one python version ships on several tebako lines and every line stays addressable. A build-variant python (3.13.15-jit) keeps its suffix inside the composite; the resolver's plain-wins rule (spec 05 §5) ranks the plain line above it, and the split of the composite against the artifact-stem witness is unambiguous (verified against the shipped split_line_id).
• Platform rows mirror the shard's env-image artifact + sha256, mapped through TebakoPythonBuilder::Platform::TPKG_TRIPLETS (the repo's single owner).
• publish.yml: the release job becomes "Audit the release + publish the registry" — the ruby grammar's two steps (render, then bot PR with auto-merge). The bot PR rides the TEBAKO_CI_PAT_TOKEN || GITHUB_TOKEN grammar (the header's runner-token deviation stays for the audit; the PR needs the PAT — a runner-token PR triggers no checks and main is protected). Workflow permissions gain pull-requests: write.
• tpkg-registry.yaml — the seed: the renderer's own output over the published v0.2.0 release (33 shard rows: 3.11.16 / 3.12.14 / 3.13.15(+jit) / 3.14.7(+jit) × the shipped platforms).

Evidence

• bundle exec rspec — 40/40 green (20 new renderer examples: derivation, composite sort + jit plain-wins, reline coexistence, same-line union, withdrawn preservation, engine backfill, byte-idempotency, and every named refusal: stale tebako line, unknown platform, duplicate triplet, malformed/absent image block, missing keys, no release, no shards, non-composite hand-edit).
• Live render of the real v0.2.0 release produces exactly the seeded file.
• End-to-end dogfood (product-side build with the composite-row fix): fresh store, this registry serving as the factory mirror → hello-python's bare >= 3.13, < 4.0 edge resolves through channel 3 to 3.14.7-0.2.0, downloads from the v0.2.0 release (shard-first acquisition), and prints Hello from tebako (python 3.14.7, darwin). No config pin.

Notes

• Draft per repo policy — owner merges.
• Once merged, the next publish's bot PR re-renders over the same shards and finds the registry unchanged (the idempotency spec proves the render is a fixed point), so the step is a no-op until the next release line.