chore(deps): bring chia declarations onto the chia-wallet-sdk ceiling

[MichaelTaylor3d]

DRAFT — DO NOT MERGE. Handing back for the gate round.

Slice of https://github.com/DIG-Network/dig_ecosystem/issues/3161 for DIG-Network/digs.

The target is the chia-wallet-sdk ceiling, not crates.io latest: the SDK's latest is
0.36.0 and it resolves the 0.36.1 primitives, so the 0.48.x primitives are unreachable.
A crate already on the ceiling is compliant; being above it is the defect.

Two fixes were in scope. One landed. One is BLOCKED upstream and is reported rather than
forced — the delta does not line up, and bridging two SDK lines with a shim would be the
byte-drift class §4.1 exists to prevent.

---

1. digstore-crypto — LANDED: chia-bls = "=0.45.0" -> "0.36.1"

This was the third of the three splits the epic is named for, and the one above the ceiling.

Why the exact pin existed

No reason was ever recorded, and the pin does not appear to have been deliberate.
git log -L on the line resolves to a single commit:

5fe545e  chore(crypto): pin chia-bls=0.45.0 and scaffold digstore-crypto manifest
         Michael Taylor, 2026-06-08

That is the commit that created the manifest — the pin was born with the scaffold, carried
no explanatory comment, and predates the SDK ceiling being understood. Nothing in the crate
depends on 0.4x behaviour. I judged the reason stale and lowered it; the replacement carries
a comment stating the ceiling so the next reader does not have to re-derive this.

Why nothing caught it for ~11 weeks — the important part

digstore-crypto wraps every chia-bls type in an opaque newtype
(pub struct PublicKey(ChiaPublicKey), private field) and returns digstore_core::Bytes48
/ Bytes96. Verified: no chia_bls type reaches its public API, and no consumer crate
names chia_bls at all.

So a wrong version here fails silently, not loudly. The compiler structurally cannot see
the split — it would simply have produced two different BLS implementations in one workspace
with no diagnostic. The only thing standing between that and a signature-verification
divergence is the frozen known-answer vector set. That is the direction this fails in, and it
is why the golden evidence below is the whole proof rather than a formality.

BLS evidence — goldens reproduce BYTE-UNMODIFIED

crates/digstore-crypto/tests/fixtures/bls_vectors.json is unchanged in this diff
(git status reports nothing under tests/fixtures/).

committed_bls_fixture_matches_generated is load-bearing, not vacuous — I checked that
BlsFixtureSet::generate() genuinely recomputes: it walks four fixed seeds and calls
bls_keygen / bls_sign against the live crate, then compares to the parsed on-disk
file. It does not reload the fixture. Any change to keygen or AugScheme signing output would
change pubkey_hex / signature_hex and fail the comparison.

test committed_bls_fixture_matches_generated ... ok
test fixture_set_self_verifies_and_tags_scheme ... ok
test chia_aug_scheme_known_vector ... ok

The 0.45 -> 0.36.1 move therefore altered no cryptographic output and required no source
change — the API this crate uses (sign / verify / SecretKey::from_seed / to_bytes /
from_bytes) is identical across both lines. This matches the dig-capsule precedent.

Lock effect

Removes the whole orphaned 0.45 family: chia-bls 0.45.0, chia-sha2 0.45.1,
chia-traits 0.45.1, chia_streamable_macro 0.45.1. chia-bls lines go 4 -> 3
(was 0.28.2 / 0.36.1 / 0.42.1 / 0.45.0).

The two survivors are not this repo's declarations and are not fixable here — they are
deep transitives of the SDK itself, exactly the case CLAUDE.md §2.4b calls out:

chia-bls v0.42.1 <- chialisp v0.4.6 <- chia-sdk-types 0.34 <- ... <- chia-wallet-sdk 0.34
chia-bls v0.28.2 <- clvmr v0.16.4   <- chia-consensus 0.36.1 <- chia-sdk-driver 0.34 <- ...

---

2. digstore-chain — BLOCKED, comment only, no version change

Intended: chia-sdk-coinset / chia-sdk-test / chia-sdk-types / chia-wallet-sdk
0.34 -> 0.36.0. I made that change, measured it, and reverted it.

datalayer-driver 4.0.0 is the latest published release and hard-requires
chia-wallet-sdk ^0.34.0. It is not optional here: digstore-chain passes DataLayer
singleton types straight across the SDK boundary, so moving only this crate resolves
chia-sdk-driver twice and the build fails with the two lines meeting in singleton.rs:

error[E0432]: unresolved imports `chia_wallet_sdk::driver::Verification`,
              `VerificationAsserter`, `VerifiedData`     (removed in 0.36)
error[E0308]: mismatched types  --> crates/digstore-chain/src/singleton.rs:108, 148, 210, 248, 974
              expected `DataStore` (chia-sdk-driver 0.34)
              found struct `Datastore<DataStoreMetadata>` (chia-sdk-driver 0.36)

The rest of the family has already moved — the holdout is singular:

crate	latest	chia-wallet-sdk req
dig-wallet-backend	0.31.0	^0.36
dig-cat / dig-tips / dig-offers	0.3.0	^0.36
dig-options	0.4.0	^0.36
datalayer-driver	4.0.0	^0.34.0

Unblocked by a datalayer-driver release onto 0.36; then this crate and dig-wallet-backend
move together in one cascade. Recorded as a manifest comment in the crate's existing
house style (it already documents a deliberate dig-constants hold for the same
splits-the-tree-rather-than-advancing-it reason), so the next lane does not repeat this.

This needs a child ticket on the epic for the datalayer-driver release.

---

Blast radius checked

• digstore-crypto is depended on by 9 crates (dig-client-wasm, cli, compiler, guest,
  host, prover, remote, stage, store) — effectively the whole workspace. Its public surface is
  chia-free newtypes, so the radius is behavioural (BLS output), not type-level; the golden KAT
  is the gate on that radius and it is green.
• digstore-chain is depended on by dig-resolver, cli, subscription — untouched apart from a
  comment.

Verification

gate	result
cargo fmt --all --check	exit 0
cargo clippy --workspace --all-targets --locked -- -D warnings -A … (CI's exact line)	exit 0
cargo build --workspace --locked	green
cargo test --workspace --locked	1571 passed, 0 failed, 169 suites
cargo deny check advisories bans sources	advisories ok, bans ok, sources ok
scripts/check-workspace-dep-versions.sh	all in-repo workspace dependencies declare version 0.28.1

Installed binary (§3.5)

Guest wasm built first (cargo build -p digstore-guest --target wasm32-unknown-unknown --release), then cargo install --path crates/digstore-cli --force --locked (exit 0):

digs 0.28.1
dig-store 0.28.1

• scripts/local-push-test.sh — 5/5 pass, push/pull/clone over a real in-process §21
  server. This exercises the BLS request-signing path (sign_request / verify_request)
  end-to-end under the new chia-bls, including
  clone_rejects_unauthenticated_or_forged_head.
• Headless digs compile roundtrip on the installed artifact (no chain, no spend):
  deterministic root bb53bead…8d77, exit 0.

init was deliberately not exercised — it mints on mainnet and nothing here needed it.

Leftover agent worktree

.claude/worktrees/agent-afa366a6361dbae8c/ confirmed untracked and gitignored
(.gitignore:17 .claude/worktrees/), so it is not part of any published crate. Its stale
=0.45.0 copy was left alone as instructed. No finding.

Ceiling audit

.claude/scripts/chia-ceiling-audit.sh reads origin/main, not the working tree, so it
still reports the pre-merge state — currently 5 violations for apps/digs.

• 1 fixed by this PR (chia-bls).
• 4 remain after merge: the chia-sdk-* / chia-wallet-sdk entries in
  digstore-chain, all blocked on the datalayer-driver release above.

Version

Patch — dependency-only, no behaviour change. Workspace 0.28.0 -> 0.28.1, with the coupled
[workspace.dependencies] digstore-core declaration moved in lockstep (CI enforces it);
digstore-crypto 0.1.0 -> 0.1.1.

[MichaelTaylor3d]

Superseded by a fresh PR from the same branch (same head SHA 8f258f5). GitHub wedged a startup_failure run (32985164499) permanently in the ci-CI-refs/pull/56/merge concurrency group — it reports queued to the run list and completed to the cancel endpoint, so it can neither finish nor be cancelled, and it blocks every new CI run on this PR ref. Reopening under a new ref is the only way to get a clean CI run. No code change.