feat(digstore-chain): migrate off dig-l1-wallet onto dig-wallet-backend engine seam

[MichaelTaylor3d]

Summary

Migrates digstore-chain coin selection off the deprecated dig-l1-wallet onto dig-wallet-backend v0.4 (engine seam), per epic #998. Consumer adapts to the new interface; the backend is not reshaped. Replicates the proven #1004 recipe (chia-l2-consensus).

Closes #1005. Refs #998.

Call-site mapping

Old (dig-l1-wallet)	New (dig-wallet-backend)
digstore-chain/Cargo.toml: dig-l1-wallet = { git=…, tag=v0.3.0 }	dig-wallet-backend = { version = "0.4", default-features = false, features = ["engine"] } (engine-only — this crate never signs)
dig_l1_wallet::coins::selection::{select_for_spend, select_for_consolidation}	dig_wallet_backend::engine::selection::{select_for_spend, select_for_consolidation}
dig_l1_wallet::{SelectionOutcome, DEFAULT_COIN_CAP}	dig_wallet_backend::engine::selection::SelectionOutcome; COIN_CAP now a digstore-local const = 50 (bundle cost ceiling) — backend's general default is 500
select_for_spend(&records, target, "XCH", cap) -> Result<SelectionOutcome> over chia-query CoinRecords	select_for_spend(coins, target, cap) -> SelectionOutcome — speaks in chia_protocol::Coin natively (infallible)
select_for_consolidation(&records, cap)	select_for_consolidation(coins, cap) -> WalletResult<Vec<Coin>> → mapped to ChainError::Chain
bytes32_to_hex/coin_record_to_protocol_coin + to_record/from_record CoinRecord dance	removed — no longer needed; chia-query direct dep dropped

Other cleanup (#1005-specific)

• Removed the [patch."…/dig-l1-wallet"] (transitive dig-keystore = =0.1.3) from the root Cargo.toml.
• Removed the dig-l1-wallet entry from deny.toml's git-source allowlist.
• Regenerated Cargo.lock — no dig-l1-wallet, dig-wallet-backend v0.4.0 resolves from crates.io.

Behavior

No runtime behavior change: selection ordering (high-value-first, tie-broken by coin id), the 50-coin cap, and the NeedsConsolidation/InsufficientFunds distinction are identical. digstore's public API (select_xch, select_xch_coins, select_xch_for_consolidation, COIN_CAP, XchSelection) is unchanged.

Blast radius (gitnexus/grep)

Fully internal to digstore-chain: callers (send.rs, singleton.rs) use select_xch_coins/select_xch_for_consolidation/COIN_CAP — all signatures preserved, zero downstream change. No public API of the crate changed. No capability gap: every dig-l1-wallet primitive digstore used has a dig-wallet-backend equivalent (the CoinRecord glue helpers became unnecessary since the new seam is Coin-native).

Tests / gates (local)

• cargo build -p digstore-chain — GREEN against dig-wallet-backend v0.4.0.
• cargo test -p digstore-chain — GREEN (236 tests + new no_dig_l1_wallet_dependency regression guard).
• cargo fmt -p digstore-chain -- --check + cargo clippy -p digstore-chain --all-targets --all-features -- -D warnings — GREEN.
• Full workspace / §3.5 installed-binary integration + coverage run on CI.

Version

Workspace 0.16.0 → 0.17.0 (minor): dependency swap + internal cleanup, no public-API break, no behavior change.

Co-Authored-By: Claude

[MichaelTaylor3d]

Review verdict: CHANGES-REQUIRED

The code migration is clean and behaviour-preserving — nice work. Confirmed:

• dig-l1-wallet → dig-wallet-backend = { version="0.4", default-features=false, features=["engine"] } (engine-only, never signs). ✓
• select_for_spend / select_for_consolidation now chia_protocol::Coin-native; the CoinRecord to_record/from_record glue + the direct chia-query dep rightly dropped — a sound simplification, not a behaviour change. ✓
• COIN_CAP = 50 preserved everywhere. select_xch_coins calls select_xch(coins, target, COIN_CAP); every singleton.rs/send.rs caller routes through it or passes COIN_CAP explicitly. No silent jump to the backend's default of 500. coin_cap_default_is_50 green. ✓
• Cleanup correct: [patch] removed from root Cargo.toml, dig-l1-wallet removed from deny.toml allowlist, Cargo.lock regenerated (no dig-l1-wallet; dig-wallet-backend 0.4.0 from crates.io). Regression guard no_dig_l1_wallet_dependency present. ✓
• All 10 gates GREEN (build&test ubuntu+windows, version-increment, CodeQL rust/js/actions, commitlint, windows CI, dig-client-wasm gate, supply-chain audit). Zero open review threads. Version 0.16.0→0.17.0 (minor) is correct — public API + behaviour unchanged. ✓

GATING — §4.2 coherence: SPEC.md left describing the old dependency

SPEC.md §10.1 (XCH coin selection & consolidation) was NOT updated in this unit of work and is now stale/wrong. It is the normative spec, not history:

• Line ~257: "the shared primitive is dig-l1-wallet" → must be dig-wallet-backend.
• Line ~271: "Caps the attempt at 50 coins (the shared DEFAULT_COIN_CAP…)" — now factually wrong: dig-wallet-backend's DEFAULT_COIN_CAP is 500; this PR deliberately fixes digstore's own local COIN_CAP = 50 (bundle cost ceiling). The spec must state 50 is digstore-local and distinct from the backend default.
• Line ~285: "both are the dig-l1-wallet primitives (select_for_spend/select_for_consolidation)" → must be dig-wallet-backend (dig_wallet_backend::engine::selection).

Per §4.2 a change that leaves SPEC.md describing old behaviour is INCOMPLETE. Update these three references in the same PR. (Inline anchors weren't possible — SPEC.md is untouched by the diff.)

dig-constants check (HARD RULE — please answer)

1. Does anything here belong in dig-constants? — COIN_CAP = 50 is now a bare local literal, and the code comment + SPEC both state "the browser/JS spend layer uses this same boundary." If a second repo (the browser/JS spend layer) must match 50, it is a shared cross-repo constant and should live in dig-constants (+ its wasm/npm binding) and be consumed by version, not re-hardcoded in each repo. Previously it rode in via the wallet crate's shared DEFAULT_COIN_CAP; moving it to a local literal risks the exact byte-drift §4.1 forbids. Either (a) source 50 from dig-constants, or (b) if the JS layer independently pins its own 50 and the two are intentionally decoupled, correct the SPEC claim that they "agree on the exact boundary." Please confirm which.
2. Should anything here be USING dig-constants? — same COIN_CAP question; otherwise the swap looks clean.

Minor (non-gating)

• The branch commit subject uses feat(digstore-chain)!: (breaking !) but the change is non-breaking and the bump is minor. Harmless since the squash merge uses the PR title (no !) — just noting the inconsistency.

Not merging (orchestrator owns merge). Resolve the SPEC.md §10.1 staleness and answer the dig-constants question, then I'll re-review + resolve.