feat(cybergym): v3 lane bottom-fill payout curve (leader takes remainder)

[ai-hpc]

Implements jared's v3 CyberGym-lane payout curve (STAGE A of the v3 lane redesign). With fewer than five qualified miners, the bottom ranks take their fixed level shares from the bottom up and rank 1 absorbs the remainder (winner-take-most), replacing the old renormalize:

N	shares
1	[1.00]
2	[0.96, 0.04]
3	[0.89, 0.07, 0.04]
4	[0.79, 0.10, 0.07, 0.04]
5	[0.65, 0.14, 0.10, 0.07, 0.04]

Level scores are the existing TOURNAMENT_SHARES; shares always sum to 1. The change is byte-identical in cathedral-validator and cathedral-distill cybergym_tournament.py (BOUNDARY.md fork hazard), guarded by an identical golden test in both.

N=0 (empty lane) is unchanged here; the N=0->compute redirect is a follow-up (it touches the validator re-derivation and is a v3 contract-shape change).

Reward-path; not self-merged.

🤖 Generated with Claude Code

[ai-hpc]

Co-merge required (fork hazard). This _award_shares change is duplicated byte-identically in the sibling repo (cathedral-validator #146 ↔ cathedral-distill #161, per BOUNDARY.md — the two vendored cybergym_tournament.py copies must stay identical). An adversarial review confirmed they are byte-identical today and that the golden test test_award_shares_curve_is_the_fixed_v3_schedule pins the same table in both — but nothing asserts cross-repo identity, so these two PRs must land together; merging one without the other silently diverges the live payout curve from the vendored copy. (The idle-redirect PR #147 is independent — different files — but also assumes this curve on the live path.)

[wallscaler]

Reviewed from fresh clones in Python 3.11 venvs with bittensor importable, so the chain-submission tests ran here. Line numbers are on the PR heads unless marked.

PR 2: cathedral-validator #146 (same curve, vendored copy)

Artifact. scaffold/publisher/cybergym_tournament.py::_award_shares, updated expectation in test_mechanism_cybergym_adapter.py:806-811, new golden test at :822-841.
Question. Is the change byte-identical to #161, and are there any pins between the repos that must move.
Out of scope. Curve design; N=0 handling.

Verdict

• Merge in the same sitting as #161. The two PR hunks are byte-identical; no runtime pin crosses the repos for this file.

Byte-identity, verified

• The added and removed lines of the two hunks are identical (diff of the +/- lines, exit 0).
• The whole files differ only by the six-line VENDORED header at validator lines 3-8, which already differs on both mains. The header pins cathedral_distill.cybergym_tournament @ a470b59; nothing tests that pin.
• Tests: test_mechanism_cybergym_adapter.py 52 passed on the PR head, including the golden test and test_vendored_tournament_constants_match_the_mechanism.

Findings

• None.

Refuted

• "The DISTILL_CONTRACT_COMMIT pin must be bumped." Refuted: pyproject.toml:100 and cathedral_thin/integration.py:39 pin distill b2ad1edd, which predates the tournament (distill #108, 72366b5) entirely. That pin serves the receipt/lane/config contract for the optional cathedral_distill extra, and the publisher uses the vendored copy by design ("duplicate rather than depend", header lines 4-5). No bump is needed for this curve.
• "The validator re-derives the tournament and an old validator would compute different shares." Refuted: validator_thin.py never imports cybergym_tournament; it re-verifies lane mass and bindings only (:3413-3416). Authority/FULL mode refuses v3 outright (validator_thin.py:1642-1654). The curve is publisher-only at runtime.

Observations

• The VENDORED header should say the distill commit it now mirrors (the #161 merge sha) instead of a470b59. Cosmetic, but it is the only thing that records the lockstep.
• The header also cites tests/.../test_cybergym_tournament_vendored.py, which does not exist; the constants guard lives in test_mechanism_cybergym_adapter.py:813. Pre-existing drift.
• git diff of #146 against current main touches nothing else in the two files; the PR is 40+ commits behind but merges clean (GitHub reports MERGEABLE).

Questions for the author

• Bump the header sha in #146 to #161's merge commit as part of the co-merge?

Merge order: same sitting as distill #161 (rebased, README count set from collection). Either order at runtime; the co-merge is a source-of-truth discipline.

[ai-hpc]

Superseded by #239, which syncs the vendored copy to distill main's KING curve (de916cf) rather than to the older bottom-fill table this PR carried.

Context that changed since this was opened: distill #181 landed jared's KING spec on 2026-09-04 (RUNNER_UP_SHARES 0.07/0.03/0.03/0.03, king takes the residual). This PR's table (0.65/0.14/0.10/0.07/0.04, leader takes remainder) is the same shape with superseded values, so merging it would have moved the publisher onto a curve that is no longer the spec.

Your two asks are carried over into #239: the header sha now names the distill commit being mirrored, and the missing lockstep guard exists — test_vendored_award_shares_matches_distills_king_schedule pins the schedule rank by rank rather than a constant name, which is why the six-day drift this PR sat through went uncaught.