wallet: adopt the current chia-query line in dig-wallet (0.21.0 -> current, after chia-query#59)

[MichaelTaylor3d]

Task

Bring crates/dig-wallet onto the current chia-query line. It declares chia-query = "0.21.0" (crates/dig-wallet/Cargo.toml:133); current published is 0.24.0 — three minors, on the live wallet path.

Parent epic: https://github.com/DIG-Network/dig_ecosystem/issues/3194

This is not a version-number change. Two of the three minors alter what a caller SEES without altering a signature, so a caret bump that compiles is not evidence the semantics still hold.

SEQUENCING — this does not pin 0.24.0

0.24.0 carries a HIGH defect: DIG-Network/chia-query#59 — the light-client drive loop can wedge on a superseded session, freezing the coin-state cache with no rearm signal, so a consumer cannot distinguish "nothing happened" from "wedged on a dead session".

dig-wallet is exactly the consumer that defect hurts: a silently frozen coin-state cache is a wallet that stops seeing money arrive. The analysis and the code work proceed now; the exact pin is taken as the last step, after #59 lands and publishes.

Context — the surface this crate actually calls

Measured on origin/main (c0e3597), not assumed:

call site	method	delta that touches it
sage/fallback.rs:397	get_coin_records_by_puzzle_hashes	0.22.0 set agreement
sage/fallback.rs:407	get_coin_records_by_hints	0.22.0 set agreement
sage/fallback.rs:517	get_coin_records_by_parent_ids	0.22.0 set agreement
sage/chain.rs:692, sage/spend.rs:366	push_tx	0.24.0 refusal routing
sage/spend.rs:440	wait_for_confirmation	unchanged
sage/fallback.rs:571	get_coin_spend_opt	unchanged
sage/chain.rs:556, fallback.rs:375	peak_height_opt	unchanged
sage/sources.rs, chain.rs:427	ChiaQueryProvider	0.23.0 lineage walk

Those three get_coin_records_by_* calls are the wallet's coin-discovery path — how it finds the user's money — and they are where the 0.22.0 change is felt. Signatures are unchanged (Result<Vec<CoinRecord>, _>), so the compiler says nothing; the behaviour behind them is now set-agreement with a fail-closed Err(SourcesDisagree) where the old code returned whichever source answered first.

The deltas, per version

• 0.21.0 → 0.22.0 — Vec-returning router methods became fail-closed wrappers over _graded twins returning CorroboratedSet<T> with as_of_height. New SetAnswer<T> has no absence arm: an empty set is a value, disagreement is Err(SourcesDisagree), an uncorroborated set that coinset cannot second is Err(UncorroboratedPresence).
• 0.22.0 → 0.23.0 — the rival singleton lineage walk was deleted. ChiaQueryProvider::resolve_singleton_lineage delegates whole to dig_chainsource_interface::resolve_singleton_lineage_via_walk, which reads coin_record as well as coin_spend and fails closed where the old copy returned an unconfirmed derived successor as the authenticated live tip.
• 0.23.0 → 0.24.0 — unscoped FrameFanout::subscribe(capacity) removed; new mempool_refusal module; new SessionEndReason::OversizedFrame; push_tx retries one other peer on a view-dependent refusal and never consults coinset about a refusal.

Two things specific to this crate

1. mempool_refusal — adopt by re-export, delete the local copy. BUNDLE_INTRINSIC_REFUSALS (crates/dig-wallet/src/sage/chain.rs:241, 11 names) was moved byte-identical into chia_query::mempool_refusal so there would be one copy. Two copies of this list is a rival implementation of a money decision. Already tracked as #556, which this closes.

Also correct the is_definitive_rejection doc (crates/dig-wallet/src/sage/rpc.rs:2326-2335), which describes routing push_tx no longer performs.

TxStatus gets NO new field — dig-wallet builds it as a struct literal at chain.rs:876. Verified against 0.24.0: still no new field.

2. The subscribe removal is a no-op here. Measured: dig-node contains zero references to FrameFanout, FrameSubscription or subscribe_frames; its subscribe_store/unsubscribe_store are dig-node's own store subscriptions and unrelated. run_update_loop (sync.rs:1274) is a future adopter, not a current caller. Recorded so the next reader does not re-derive it.

The invariant most at risk

sage/corroborated_source.rs:312-317 documents a deliberate distinction between "the peers did not agree, or too few spoke" (→ Err) and "this source exposes no peak" (→ Ok(None)). That is NC-12 plurality, and a set-agreement adoption is exactly where it gets flattened by accident. Collapsing concurrently-queried peers to a single voice is a regression that looks like a clean refactor.

The adoption must preserve it and say how it was verified, with a test that fails without the adoption.

Constraints

• NC-12 — every dialled peer untrusted; content accepted because it verifies, never because a peer asserted it.
• §908 — the node signs nothing on the user's behalf; the user's spend key never enters it.
• chia-* moves as a set or not at all. Do not bump the chia family to 0.48: chia-wallet-sdk 0.36.0 is latest and anchors it at ^0.36.1. Verified: chia-query 0.24.0 declares the same 0.36 line as 0.21.0, so this adoption moves no chia crate.
• §2.4b — bring this crate's dig-*/chia-* deps to latest in the same PR.
• MSI caps on dig-node's version: MAJOR <= 255, MINOR <= 255, PATCH <= 65535.

Closable

Done when crates/dig-wallet/Cargo.toml declares the current non-#59 chia-query line, Cargo.lock resolves it once, the local BUNDLE_INTRINSIC_REFUSALS is gone in favour of the re-export, the is_definitive_rejection doc matches the shipped routing, the plurality distinction is shown preserved by a test, and cargo test --workspace --all-targets --all-features --locked is green.

[MichaelTaylor3d]

Analysis complete; PR #558 (draft, pin held)

Findings recorded here rather than filed as tickets (§1.3c rule 1 — a finding is a comment unless it is user-visible, touches money/custody/data-loss, or blocks a named in-flight feature). One residue was big enough to earn a child: #559.

1. corroborated_source.rs:277 — judged, and deliberately NOT un-refused here

The refusal at coin_records_by_puzzle_hash was expected to become un-refusable once chia-query shipped a graded set API. It has not become that, and un-refusing it now would be a mistake.

The graded set API 0.22.0 shipped — get_coin_records_by_puzzle_hashes_graded returning CorroboratedSet<T> with an as_of_height — lives on QueryRouter / ChiaQuery, and reaches a ChainSource through ChiaQueryProvider. CorroboratedChainSource is a different provider, backed by PeerCorroboratedReads — this node's own dialled peers — and PeerCorroboratedReads has no set read at all: its surface is coin_record_by_id_at_floor, coin_spend_at_floor, peak_height. Every read is by coin id.

So un-refusing would mean building a corroborated set read on the peer-reads path, not adopting one chia-query published. That is a feature with its own NC-12 plurality surface — how a set is normalised across peers, what a peer omitting a coin costs, what an empty answer means — and folding it into a version bump would put exactly the kind of new plurality logic inside a change nobody is reviewing as a plurality change.

On #56's untrusted wire-height bound: it is the right thing to cite when that work happens, because a set read on the peer path must hold every peer's answer to a height the node did not take on one peer's word. It is not load-bearing for this PR, because this PR adds no such read. Stating it as the justification for an un-refusal that did not happen would be a claim about safety that nothing here exercises.

The refusal's current text is also still exactly right: an empty Vec there would read as no coin pays this puzzle hash, which is a fabricated absence rather than an unanswered question.

2. SETTLED_LAG and PEAK_LAG_TOLERANCE are now rivals — same values, no live defect

chia-query 0.24.0 added peer::plurality::SETTLED_LAG = 2, whose own doc says it is "the same constant, with the same semantics, as dig-wallet's sage::quorum::SETTLED_LAG / common_height". PEAK_LAG_TOLERANCE = 3 already existed on both sides.

Not adopted in this PR, and the reason is a real distinction rather than scope-guarding: the two crates apply the same number to different quantities. dig-wallet subtracts SETTLED_LAG from the lowest claimed peak of its sample; chia_query::peer::set_agreement::common_height subtracts it from the lowest as-of height of the sources that answered. Re-exporting would unify the constant and silently imply the applications are the same. That is a plurality-semantics change and belongs in a change reviewed as one.

Values are identical today (2 and 3), so there is no live defect — only drift risk, which is why this is a comment and not a ticket. CORROBORATION_FLOOR is already adopted from chia_query::peer::plurality (fallback.rs:583), so the precedent for adopting the rest exists.

3. dig-chainsource-interface resolves TWO lines, and this PR did not cause it

Cargo.lock carries 0.1.0 and 0.3.2. chia-query 0.24.0 resolves 0.3.2 (as 0.21.0 did), and the new lineage-walk feature pulls only crates already on the 0.36 line — so the split is pre-existing and untouched here. Two other consumers hold the 0.1.0 line. Recorded so the next reader does not attribute it to this bump; not fixed here because it is a different family's cascade.

4. dig-node is at MINOR 254 of a 255 cap

The MSI ProductVersion limits are MAJOR <= 255, MINOR <= 255, PATCH <= 65535, and the root workspace version is 0.254.x. One more minor bump exhausts the range. Nothing is broken today and this PR takes a patch, but a feat in this repo now costs a decision about the major, and there is no reason to be surprised by that mid-release.

[MichaelTaylor3d]

State — resume-ready

Branch: loop/chq-adopt-dig-wallet · HEAD 169e8df1100881f28db4e9e1dda19ce52f3e93ec · PR #558 (DRAFT)
Worktree: C:\tmp\worktrees\dn-chq-adopt (its target/ is intentionally retained — the gate round has not run, so "nothing left to build/test" is not yet true; reclaim it after merge)

Done

• chia-query 0.21.0 -> 0.24.1, declared as a patch floor so 0.24.0 (chia-query#59, the drive-loop wedge) is unresolvable while later patches flow. Cargo.lock read back: resolves once, at 0.24.1.
• chia_query::mempool_refusal adopted; the local BUNDLE_INTRINSIC_REFUSALS and its ~60 lines of exclusion rationale deleted. The "{verdict}: {reason}" split stays here.
• Both is_definitive_rejection doc sites corrected for the 0.24.x push routing.
• dig-node 0.254.77 -> 0.254.78 (root Cargo.toml, then cargo update -w --offline before staging the lock).
• Four new tests; two existing fixtures re-routed. Three revert-proofs, each confirmed RED-with-green-control.

Verified

cargo test --workspace --all-targets --all-features --locked exit 0 — 3089 passed, 0 failed, 3 ignored. cargo clippy --workspace --all-targets --locked -- -D warnings exit 0. cargo fmt --all --check exit 0.

All 14 CI checks pass on 169e8df1. check-merge-preconditions.sh --allow-draft run unpiped: RESULT: preconditions MET [EXIT 0], all six required contexts asserted BY NAME as SUCCESS, zero unresolved threads.

closingIssuesReferences re-verified from the API after the final push: [556, 557] — parsed as two, not one.

Next action

The gate round, then undraft and merge. This lane does not undraft and does not merge. Gate tier: the diff touches the wallet's coin-discovery path and the mempool-refusal classifier, both money-adjacent, so the full triple is the right tier rather than a single correctness gate.

Not done, and deliberately

• corroborated_source.rs:277 is NOT un-refused. CorroboratedChainSource is backed by PeerCorroboratedReads, which has no set read at all — un-refusing means building a corroborated set read on the peer path, not adopting one chia-query published. chia-query#56's untrusted wire-height bound is not load-bearing for this PR, because this PR adds no such read; it is what would make that future work safe. Reasoning in full on the PR.
• dig-node-control-interface 0.31 -> 0.32.1 split out as adopt dig-node-control-interface 0.32.x and serve control.wallet.resetCoinDb #559 (§2.4b scope limit).
• Blast radius was established by grep + direct read, not gitnexus — §2.0 permits the fallback and requires it be stated. The registered indexes are stale by construction and a stale impact returns a false-safe zero, so no index was trusted here.