feat(distill): bump the contract pin to 4bc31563, nine days of drift

[wallscaler]

@ai-hpc please review. This is the distill integration PR; #138, #139 and #140 are closed as stale.

The state I found

Nothing was advancing the distill pin:

main pinned   b2ad1edd  2026-08-05T05:48Z
distill main  4bc31563  2026-08-14T01:44Z    52 commits, 71 files ahead

Worse, the two open PRs whose stated job was "pin the current distill contract" both pointed backwards:

PR	pin	dated	vs main
#139	63ae4802	2026-08-04 23:19Z	6.5h older
#140	6203fc18	2026-08-04 21:19Z	8.5h older

Both were current when written. main passed them, nobody re-checked, and merging either would have regressed DISTILL_CONTRACT_COMMIT and the integration extra. Closed rather than merged.

I also closed #138 (tournament lane): rebased onto main it is empty. cybergym_tournament.py, mechanism_cybergym_adapter.py and its tests are already there.

Why this one matters for launch

Two things in the gap bear directly on #107:

• distill#114 emits nonce + dispatched_units in the score report. Those are exactly the tournament inputs our vendored adapter already reads and treats as optional. Until the pin moves, the producer side of that contract is not what we are compiled against.
• distill#122 adds reseal_task.py, re-sealing bugs into admission-passing private tasks. That is gate 4 tooling, and gate 4 is currently the least evidenced of the four.

Also in the 52: the trustless receipt gate (#113), attested-receipt admission with unattested epochs gated at export (#99), and the reference-miner canary for sealed corpora (#124).

Change

Two lines, kept in lockstep as test_integration_admission_gates.py:42 requires:

• pyproject.toml integration extra
• cathedral_thin/integration.py DISTILL_CONTRACT_COMMIT

Plus the pin comment, which still described what b2ad1edd added as though it were current.

What I cannot vouch for

I have not read all 52 commits. This bump is deliberately mechanical, and the Integration lane is the actual reviewer: it installs the extra and runs the contract-dependent thin tests that importorskip without it. If the contract moved incompatibly, that job fails and this PR is the cheapest place to find out.

Your call on whether 4bc31563 is the right target or whether a specific earlier commit is the reviewed one to land on. I picked distill main head because no other commit had a claim to being current.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[wallscaler]

CI found the incompatibility, and it is a deliberate one

Integration lane, 3.11 and 3.12 all fail on the same thing. Publisher suite passes.

error: refusing to export CyberGym epoch 11: this score database does not record
whether Intel-TDX attestation was enforced, so its solves cannot be shown to be
attested. Re-close the epoch with a current build, or pass allow_unattested=True
(CLI: --allow-unattested-e2e) if this is a loopback preview whose report will
never reach a production intake.

tests/thin/test_cybergym_prelaunch_e2e.py:366  AssertionError: assert 2 == 0

This is not the bump breaking something. It is distill#99 ("prove the attested-receipt admission path and gate unattested epochs at export") doing its job: the newer build refuses to export an epoch whose score DB cannot show attestation was enforced. Our harness builds exactly such an epoch.

# tests/thin/test_cybergym_prelaunch_e2e.py:300
attestation_required=False,
# :356 -- mark_epoch records state/scored_miners/at, and nothing about enforcement
score_store.mark_epoch(SOURCE_EPOCH, state=EPOCH_CLOSED, scored_miners=1, at=...)

The decision is yours, @ai-hpc, because the two options mean different things

A. Pass --allow-unattested-e2e. One line. The error explicitly offers this for "a loopback preview whose report will never reach a production intake", and the fixture already sets attestation_required=False, so arguably this E2E was always the unattested path and the flag just makes that explicit.

B. Make the harness record enforcement and close an attested epoch. More work, and it makes a test named prelaunch_e2e actually exercise the gate that guards launch.

I lean B on the name alone: if this is the prelaunch E2E and gate 2 is about proving one contract end to end, an E2E that opts out of the attestation gate proves less than its name claims. But A is legitimate if this test's job is transport plumbing and the attested path is covered elsewhere, which you would know and I do not.

I have deliberately not picked. Choosing A silently would weaken a launch gate's evidence in a PR whose stated scope is a version bump.

Everything else about the bump is clean

Publisher suite passes, which covers the vendored tournament adapter against the new contract. The lockstep assertion (test_integration_admission_gates.py:42) is satisfied. So this single gate is the whole delta between main's pin and nine days of distill.