chore(deps): adopt chia-sdk-* 0.36.0 ceiling

[MichaelTaylor3d]

Task

Bring dig-chainsource-interface onto the chia-wallet-sdk 0.36.0 ceiling.

Parent epic: https://github.com/DIG-Network/dig_ecosystem/issues/3161
Closes #5

Why this repo first — it is an ecosystem blocker

Published 0.3.1 ships internally split: chia-protocol/chia-puzzle-types/clvm-traits/clvm-utils at ^0.36.1 beside chia-sdk-driver/chia-sdk-test/chia-sdk-types at ^0.34. The split lives inside the published version, so no consumer could escape it by bumping.

Changes

dep	from	to
chia-sdk-driver	0.34	0.36.0
chia-sdk-types	0.34	0.36.0
chia-sdk-test (dev)	0.34	0.36.0
chia-puzzles	0.20	0.20.3 (pinned to ceiling)
clvmr	0.16	0.16.2 (pinned to ceiling)

The ceiling is not "latest": the primitives publish at 0.48.0 but chia-wallet-sdk cannot reach them, so 0.36.1 primitives beside 0.36.0 chia-sdk-* is the coherent maximum. The primitives were already at their ceiling and are deliberately left alone — bumping them to 0.48 would re-split the crate, not modernise it.

Evidence

What the lock actually does — corrected

An earlier revision of this body claimed the chia-sha2 0.34.0 line "is gone" and that the crate ends with one fewer chia-* line than origin/main. Both claims were false. Measured at head:

• chia-sha2 0.34.0 is still present, identically in origin/main and at head. It is reached via clvmr 0.16.4, which vendors it internally; nothing in this PR could have removed it.
• The chia-*/clvm* line count went UP, not down: 29 -> 31. The two additions are chia-sdk-coinset 0.36.0 (pulled by chia-sdk-test 0.36.0, dev-only) and chia-serde 0.36.1 (a 0.36.1 split-out, pulled by chia-protocol/chia-bls).

The change is still right, for the reason #5 actually states — it removes the declared split. That is the whole defect: a crate whose own manifest names two minor lines of one family. What this PR removes from the resolved lock is precisely the 0.34.0 line of the crates this manifest declares:

resolved line	origin/main	head
chia-sdk-derive / -driver / -signer / -test / -types	0.34.0	0.36.0
chia-sdk-coinset	—	0.36.0 (new, via chia-sdk-test)
chia-serde	—	0.36.1 (new, via chia-protocol)

The older lines that remain, and why they are fine (each traced through the lock, not assumed):

• chia-sha2 0.34.0, chia-bls 0.28.2, chia-traits 0.28.2, chia_streamable_macro 0.28.2 — all reached from clvmr 0.16.4, internal to the CLVM evaluator.
• chia-bls 0.42.1, chia-traits 0.42.1, chia_streamable_macro 0.42.1 — reached from chialisp 0.4.6, itself pulled by chia-sdk-types and rue-lir.
• clvm-traits 0.28.1 — reached from rue-lir 0.8.5.

None of these is declared by this crate, and none reaches a public signature: the only chia type on this crate's public surface comes from chia-protocol, and chia_bls/chia_traits/chia_sha2 appear nowhere in src/. cargo tree -d therefore cannot be a gate here — chia-wallet-sdk fails it on its own vendored graph.

The rest

• Zero source churn in the adoption itself. The only src/-adjacent addition is the new regression test below.
• Full suite green: 69 tests (66 pre-existing + 3 new), including the lineage_walk and hostile_lineage_walk suites, which authenticate the singleton walk against real spends from the 0.36.0 simulator (chia-sdk-test) through the 0.36.0 SingletonLayer.
• cargo clippy --locked --all-targets --all-features -- -D warnings exit 0; cargo fmt --all -- --check exit 0.

The regression guard (#5 is a defect ticket, so it gets a test)

tests/manifest_chia_coherence.rs fails if this crate's chia-* declarations ever split across two minor lines again.

An earlier revision of this body argued that no test could distinguish the bump. That is true of behavioural tests — both halves of a split run correctly in isolation, which is exactly why the split shipped — but it searched for the wrong property. The defect was manifest coherence, and manifest coherence is mechanically assertable.

• Asserts the manifest, not the lock. deps: 0.3.1 ships internally split (chia-sdk-* on 0.34 beside chia-* on 0.36.1) — publish 0.3.2 #5 is about what this crate declares. The lock legitimately carries older chia lines this crate neither chooses nor controls (the clvmr/chialisp internals listed above), so a lock-based guard would need name-by-name carve-outs and would go red whenever an upstream evaluator re-vendored something.
• Per-FAMILY MAJOR.MINOR agreement, not global equality. The ecosystem ceiling is deliberately non-uniform — chia-sdk-* 0.36.0, primitives 0.36.1, chia-puzzles 0.20.3, clvmr 0.16.2 — so a guard asserting "all chia crates share one version" would be red on correct code. Three families are named: the chia 0.36 line (chia-sdk-* + the chia/clvm primitives, the two the defect split apart), the chia-puzzles 0.20 line, and the clvmr 0.16 line.
• Pins the exact declared set, so a chia dependency added on a foreign line, or silently dropped, also fails.

Revert-proof — the 0.34 split reintroduced, restored by file copy:

$ # chia-sdk-driver/-types set back to "0.34"
$ cargo test --offline --all-features --test manifest_chia_coherence
running 3 tests
test every_declared_chia_dep_belongs_to_a_classified_family ... ok
test the_declared_chia_dependency_set_is_exactly_the_expected_one ... ok
test every_chia_family_declares_a_single_minor_line ... FAILED

---- every_chia_family_declares_a_single_minor_line stdout ----
assertion `left == right` failed: #5 REGRESSION: `chia-sdk-driver` is declared at 0.34 but
the chia 0.36 line (chia-sdk-* + the chia/clvm primitives) is pinned to 0.36.x. Two minor
lines of one chia family in one manifest is the internal split that shipped as 0.3.1.
  left: "0.34"
 right: "0.36"

test result: FAILED. 2 passed; 1 failed

Restored, and green again at the real versions — which is also the truthful control that the guard does not fire on the legitimate non-uniform ceiling:

$ cargo test --locked --all-features --test manifest_chia_coherence
test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out

Also in this PR

SPEC.md claimed the crate "does not depend on chia-puzzle-types, chia-puzzles", which stopped being true when the non-default lineage-walk feature was added. Corrected to state the real shape and the ceiling rationale. Pre-existing drift, fixed inline because it is exactly the dependency shape this PR changes.

Bump

0.3.1 -> 0.3.2 (patch).

An earlier revision of this body proposed 0.4.0, justified as semver-breaking for lineage-walk consumers. That rationale was checkably false and has been corrected. The public surface was walked:

• Every chia-sdk-*, clvm* and chia-puzzle* import in the crate is confined to src/walk.rs:44-51.
• No type from any of them crosses a public signature. LineageWalkError<E> carries only E/String/Bytes32/usize/Duration; walk_singleton_lineage, walk_singleton_lineage_bounded, walk_singleton_lineage_within and resolve_singleton_lineage_via_walk take and return Bytes32/SingletonLineage/WalkBounds/ChainSourceError. MAX_HOP_CLVM_COST is a u64, named for CLVM but not typed by it.
• The one chia crate that is on the public surface — chia-protocol, supplying Bytes32/Coin/CoinSpend/Program — is unchanged at 0.36.1, identical in origin/main and at head.

So no consumer, including a lineage-walk one, can observe this bump. Nine consumers pin "0.3" and only dig-app enables lineage-walk; shipping 0.4.0 would have forced eight repos to edit manifests for a change that cannot reach them, in the middle of an epic whose purpose is reducing version churn.

WIP — DO NOT MERGE.

[MichaelTaylor3d]

Correctness gate — CHANGES-REQUIRED

Head reviewed: 6d6bf425f11933e2855e8c2a0d255d8705b4cae7.

The code is clean and the dependency outcome is correct — pins are on the true non-uniform ceiling with no normalization to 0.36.1, the lock collapses chia-sdk-* to a single 0.36.0 line, 66 tests pass, and clippy is exit 0. Three findings, all in the manifest/record rather than in src/, ranked below and posted as inline threads.

What I verified as CORRECT

• The ceiling pins are right and were not normalized. chia-puzzle-types/clvm-traits/clvm-utils at 0.36.1, chia-puzzles at 0.20.3, clvmr at 0.16.2, chia-sdk-* at 0.36.0, chia-bls at 0.36.1. Checked live against chia-ceiling-audit.sh. This was the epic's most likely error and it is absent.
• The split is discharged at its root. At head the lock carries one line each of chia-sdk-driver/types/test/derive/signer at 0.36.0, and one chia-protocol at 0.36.1. A consumer can no longer inherit the split.
• SPEC.md is now true. The corrected §1 text matches the manifest exactly, and I swept the rest of the file for the superseded phrasing — nothing else contradicts it.
• Closes is bare and unbackticked, correctly targeting issue #5.
• Cargo.lock self-version is 0.4.0, matching Cargo.toml; --locked will not trip.
• Residual-duplicate claim spot-checked and TRUE. I traced chia-sha2 0.34.0 with cargo tree -i: it is reached only via clvmr 0.16.4 (an internal dependency of chia-consensus/chia-protocol), and chia_bls/chia_traits/chia_sha2 appear zero times in src/. cargo tree -d is correctly not usable as a gate here.
• Full suite green at head: 66 tests across six binaries. cargo clippy --locked --all-targets --all-features -- -D warnings exit 0, read unpiped.

Ranked findings

1. Cargo.toml:38 — the bugfix has no regression test. Issue #5 is a defect ticket about a manifest-level split, and nothing mechanically prevents the split recurring.
2. Cargo.toml:11 — 0.4.0 is justified by a claim the source does not support, and it forces a ~9-consumer manifest cascade. Needs a true rationale, or 0.3.2.
3. Cargo.toml:66 — the PR body's lock evidence is factually wrong. The chia-sha2 0.34.0 line is NOT gone at head, and head has MORE chia-* lines than origin/main, not fewer.

Finding 1 also answers the lane's honestly-reported verification gap. The lane is right that no behavioural test distinguishes 0.34 from 0.36 — the puzzle did not change, so any such test would be manufactured, and it was correct not to write one and to say so plainly. But that gap does not mean nothing is testable: the property this PR actually restores is manifest coherence, and that is mechanically assertable. See thread 1.

Note on the verdict mechanism

Recorded as a comment review because a verdict-bearing review event (REQUEST_CHANGES as much as APPROVE) is HTTP 422 on a same-identity PR. The three inline threads are what bar the merge under required_conversation_resolution — not this prose.

[MichaelTaylor3d]

Superseded by a fresh PR on the same branch: this PR stopped receiving pull_request workflow runs after its first merge-sha, so all four required contexts read ABSENT and it could never satisfy §2.4a. Content, branch and head are unchanged; the gate verdict and its three resolved threads stay here for the record.