Protect main and publish immutable Prob4D release tags

[FlorianPfaff]

Purpose

Complete the repository-governance and distribution boundary that cannot be established by source changes alone.

Current repository metadata shows that main has no active branch protection/ruleset and the repository exposes no Git tags, although package metadata and release documentation identify Prob4D 0.4.1 and 0.5.0.

This issue tracks repository settings and immutable publication only. It must not alter historical evidence, estimator semantics, or content-addressed provenance.

1. Protect main

Create an organization/repository ruleset for the default branch with all of the following:

• require pull requests before merge;
• require at least one independent approval;
• dismiss stale approvals when the head changes;
• require all review conversations to be resolved;
• require CODEOWNER approval for .github/, release metadata, provider/observation/calibration contracts, and prob4d.api.*;
• prevent force pushes and branch deletion;
• require the exact-head checks that own repository, quality, security, provider, ecosystem, and portability validation;
• do not allow an Actions workflow or PR author to bypass independent review for claim-bearing or privileged changes; and
• retain administrator bypass only for documented incident recovery, not ordinary merging.

Required checks should include the current authoritative checks and, after PR #241 merges, Contract portability:

• Tests;
• Fail-closed quality;
• Security scanning;
• Provider batch preflight;
• Ecosystem installed-wheel release capsule; and
• Contract portability.

Add a second independent maintainer or organization team to CODEOWNERS for workflow, contract, and release boundaries before enforcing code-owner review.

2. Publish immutable release tags

Independently verify the exact historical commits and release documents before creating tags. The apparent release-boundary candidates are:

• 0.4.1 candidate: 83f83f9b9a69e5a76fb7675fbd0875e9eea3091d;
• 0.5.0 candidate: 20830d39502aea84ccadf5d7611423517fa9531c.

Do not tag a newer development head as an old release. Confirm each candidate against:

• pyproject.toml at that revision;
• the matching docs/releases/<version>.md;
• CHANGELOG.md;
• the public API manifest;
• source-distribution boundary tests; and
• any frozen wheel/source digests already referenced by evidence capsules.

After verification:

1. create signed annotated v0.4.1 and v0.5.0 tags at the exact release commits;
2. publish GitHub releases containing the wheel and source distribution;
3. attach a SHA-256 manifest, SBOM, public API manifest, provider-schema compatibility manifest, and build provenance/attestation;
4. record the compatible BayesianPhysTwin and Causal4D release ranges; and
5. verify the three-repository capsule from released wheels rather than editable checkouts.

Acceptance evidence

Close only after retaining evidence that:

• main is protected by the intended ruleset;
• a PR without independent approval cannot merge;
• stale approvals and unresolved conversations block merging;
• force push and deletion are blocked;
• both release tags resolve to independently verified historical commits;
• release assets install in isolated environments and match their published digests; and
• the installed-wheel ecosystem contract passes from those assets.

Scientific boundary

Branch protection and release publication establish governance, retrieval, and software reproducibility only. They do not establish provider accuracy, uncertainty calibration, BayesianPhysTwin benefit, Causal4D intervention benefit, deployment safety, or state of the art.

[FlorianPfaff]

Release-provenance implementation is now available in draft PR #263 at exact head f3c3b038869f978baa6985e2230946f856ef76b6.

It closes the source-side part of the ordinary-wheel identity gap by generating a package-byte-bound build identity for:

• direct wheels from a clean Git checkout;
• source distributions from the same checkout;
• wheels rebuilt from the identified source distribution; and
• PEP 660 editable installs through complete clean-checkout attestation.

The exact-head Release build identity workflow is green. It separately verifies the expected git_checkout versus inherited_source_archive provenance, installs all three distribution routes outside the checkout, and proves that installed-package tampering fails closed. The branch is one commit on current main and opens no scientific data or outcomes.

This does not complete issue #243: protected-branch settings, an independent CODEOWNER/reviewer, independently verified historical release commits, signed immutable tags, release assets, SBOM/attestation, and released-wheel three-repository verification remain outstanding.