Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Doc sync — 686430a4 (docs/kv-keys.md)

Trillian audited the k/v key reference against current source and corrected three stale entries. All align the doc with code changes already described in this PR:

• Migration sentinel — was documented as a single global det:migration:finish_unwire:v1 with constant SENTINEL_KEY. Now correctly det:migration:finish_unwire:<network>:v1 (per-network, via sentinel_key_for(network)), consts SENTINEL_KEY_PREFIX + SENTINEL_KEY_VERSION. Tracks SEC-001.
• Single-key metadata sidecar — ImportedKey field list extended from 3 → 5 (has_passphrase, passphrase_hint). Tracks SEC-002 Option C.
• HD seed envelope encoding — value is now [ version byte | bincode::serde(payload) ], not bare bincode::serde. Tracks SEC-005.

All other sections (17 platform-wallet keys, DashPay sidecar, settings, wallet selection, summary counts) verified accurate — no drift. Doc-only; no source touched.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

SPV-start fix (PROJ-001, CRITICAL) + consolidated gap report — 8d35933e

Bug: the Settings "Connect" button did nothing and SPV stayed idle. Root cause: AppContext::start_spv() was an inert Ok(()) compile-floor stub and WalletBackend::start() (the only spawner of the SPV run loop) had zero callers — so SPV / platform-address / identity sync never started in any path (Connect, auto-start, MCP, network switch).

Fix (3 commits):

• 42388c4b — wire start_spv() → WalletBackend::start(); add a per-instance StartLatch so SPV can't be double-driven.
• 3165f98c — route all callers through one idempotent async chokepoint AppContext::ensure_wallet_backend_and_start_spv() (wire-then-start); fixes the boot auto-start race (sync constructor fired before the backend was wired), MCP ensure_spv_synced, and network-switch restart; hoist SpvStatus::Error above the DAPI gate so chain-sync failures aren't masked as "Disconnected".
• 36f5a982 — surface start/wiring failures to the user (indicator → Error in the chokepoint; actionable banner at the Connect handler); replaces the dead AppAction::Custom no-op.

QA: two full Marvin rounds (caller-integration focus). All findings resolved; 2 LOW residuals (user-facing wiring-failure feedback + a forward-compat dead branch) closed by 36f5a982. 571 lib tests pass (+8), clippy/fmt clean. 8 new offline tests cover the start-path gating. The one kittest failure (tc_sk_004) is confirmed pre-existing.

Consolidated gap audit — 2313089a (+ status update 8d35933e)

docs/ai-design/2026-06-01-pr860-gap-audit/gaps.md — a whole-PR audit by project-reviewer Adams. 21 confirmed gaps (1 CRITICAL, 4 HIGH, 6 MEDIUM, 7 LOW, 3 INFO), each with file:line. Highlights:

• PROJ-001 (CRITICAL) — resolved on-branch (above).
• PROJ-005 (HIGH) — now the sole remaining open merge-blocker: Cargo.toml pins platform to the unreleased #3625 rev (release gate G1).
• 5 net-new findings, notably PROJ-004 (HIGH) — DashPay outgoing contact-request xpub derivation uses placeholder seed material (let wallet_seed = sender_private_key;), the substrate behind the TC-037/043 association symptom.
• 4 seeded "gaps" verified already-fixed (eager-init hard-failure → graceful warn, TC-019 precedence, core_backend_mode removal, the 5-manager readiness gate).

Remaining open gaps are catalogued in the report (not filed as separate issues by request).

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

DetKv per-object refactor + platform bump to 35e4a2f — 129d54d0

Reseats DET's KV layer onto upstream's per-object KvStore and retires two of three duplicate caches. 7 commits:

• 549ddfa1 — honest error when wallet data is from a newer app version (WalletDataTooNew, replaces the misleading "check disk space" for schema-version skew).
• dbd94356 — reseat DetKv on the 08b0ed9 per-object KvStore via a DET-side DetScope { Global, Wallet, Identity, Token } (maps to upstream ObjectId only inside kv.rs — no type leak); isolate the platform-address and token-balance caches behind PlatformAddressView/TokenBalanceView seams.
• 845ff685 — honest error for an incompatible on-disk schema (WalletDataIncompatible, divergent-migration case); finish the token-balance seam.
• fb50c044 — bump platform to 35e4a2f (meta_* FK relaxed to soft-cascade triggers; public per-(identity,token) balance reader).
• f6119de7 — delete the det:token_balance cache; balances now read live from upstream IdentitySyncManager via a lock-free snapshot bridge (pre-sync shows "syncing", not 0).
• d7ac9a06 — promote identities + DashPay overlays to Identity scope (identities/top-ups/scheduled-votes → Identity(id); dashpay private/address_index → Identity(owner)); Global enumeration indices; explicit cleanup (the upstream soft-cascade trigger doesn't fire for DET-only KV removals); hardened private-key Debug redaction.
• 129d54d0 — docs synced to the per-object model.

Principle applied: DET's KV stores only DET-specific metadata; canonical object state upstream owns (token balances) is read, not duplicated.

QA (Marvin, combined tree): PASS — cargo build --all-features ✓, 598 tests (597 pass, 1 ignored) ✓, clippy -D warnings ✓, fmt ✓. Zero code defects; M-DONT-LEAK-TYPES intact.

Remaining duplicate: the platform-address cache (det:platform_addr/det:platform_sync) stays, staged behind PlatformAddressView — one-line swap once upstream exposes a public per-address nonce reader (the only open platform-side dependency; the FK relaxation and token-balance reader both landed in #3625 @ 35e4a2f).

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

Mock/stub findings + SPV progress + DashPay fund-routing — 450214e5 (8 commits)

Post-35e4a2f cleanup from a mock-audit, plus a fund-routing fix the audit surfaced. All on top of the DetKv per-object refactor.

SPV / UX

• bd0ed0e4 — SPV sync progress bar restored: two UI sites read an inert SpvStatusSnapshot::default(); EventBridge::on_progress already received full upstream SyncProgress (per-phase heights) but discarded it. Routed it into ConnectionStatus (single source of truth) → determinate per-phase % bar. Also fixed two dead gates (network selector now disables mid-sync; "Clear SPV Data" gated).
• 7e2553e3 — real per-network platform activation height (was hardcoded 1).

Tokens / MCP

• 5a047357 — "Stop Tracking Balance" truly un-watches the (identity, token) pair upstream (update_watched_tokens), not just a local order prune.
• 5ba4554e — platform_withdrawals_get MCP tool: structured fields + pagination.

DashPay

• a7327e7c — contact-request expires_at derived from created_at + 7d.
• 3ac9b3b0 — update_payment_status now persists transitions (was a logging no-op). check_address_usage documented as blocked-by-design (upstream usage reader is keyed by (wallet, account-type), not arbitrary address; contact-send addresses aren't pool-managed).
• 6c520a33 — PROJ-004 (fund-adjacent): contact-request xpub now derived from the real HD seed via upstream derive_contact_xpub (was a placeholder using the ECDH private key → mis-routed contact payments). Seed handling: Zeroizing, confined to the wallet_backend seam, never in the document. Smythe-audited: SAFE.
• 450214e5 — SEC-001 (HIGH, fund-routing): receive-side DashPay derivation hardcoded coin-type 5' on all networks while the send side (now correct) uses 1' on testnet → testnet contact payments landed on un-scanned addresses (recoverable; mainnet unaffected). Fixed via a canonical coin_type_for_network helper threaded through all receive paths (incl. the DIP-15 root-encryption + auto-accept keys, same bug). Send==receive xpub now pinned by a cross-implementation equality test on both networks. Smythe-re-audited: SEC-001 RESOLVED.

QA/Security: Marvin (integration) + Smythe (two fund-safety passes) — cargo build --all-features ✓, 611 lib tests ✓, clippy -D warnings ✓, fmt ✓.

Standing gates / follow-ups (non-blocking):

• Live-network test required before trusting contact payments with funds — mainnet round-trip (real funds) and testnet (now expected to pass post-SEC-001).
• SEC-003 (G1): fund routing depends on the unreleased platform-wallet @ 35e4a2f — no mainnet release until a published rev (existing G1 gate).
• SEC-004 (LOW): auto-accept key rooted on a 32-byte private key rather than the HD seed (self-consistent, doesn't route funds) — tracked follow-up.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

Platform dep bump → ffdc28b8 + gap-audit refresh

Pushed 2 commits (450214e5..419ef952).

fd209783 — chore(deps): bump platform deps 35e4a2f → ffdc28b8 (current head of dashpay/platform#3625, a clean 15-ahead/0-behind fast-forward)

• All four platform crates re-pinned: dash-sdk, rs-sdk-trusted-context-provider, platform-wallet, platform-wallet-storage. grovestark untouched.
• Cargo.lock: 27 platform crates → v3.1.0-dev.8; 13 transitive grovedb crates moved (upstream-pinned, pulled in by the v3.1-dev merge 269e5783). Nothing stray.
• Zero source fallout — no DET files needed editing. Picks up two fixes that sit under our seam:
  • 1053caa2 platform-wallet-storage single-read KvStore::get (TOCTOU, CMT-001) — public get/put/delete/list_keys signatures unchanged; our DetKv envelope intact, all 9 adapter tests pass.
  • 73eb0ae0 platform-wallet SPV client deadlock-on-stop — behavioral, no API change; WalletBackend::shutdown/stop_spv compile untouched.
• Build + clippy (-D warnings) + nightly fmt: all green.
• Caveat: verified API-clean, but the runtime behavior of the TOCTOU/deadlock fixes is upstream's to validate (needs the #[ignore] backend-e2e suite on a funded testnet wallet).

419ef952 — docs(gap-audit): refresh gaps.md to as-of-450214e5 state

• 5 PROJ gaps flipped RESOLVED (re-verified against source, not commit messages): PROJ-001 (SPV start wired), PROJ-003 (update_payment_status persists), PROJ-004 (HD-seed contact xpub + SEC-001 per-network coin-type), PROJ-006 (per-network activation heights), PROJ-014 (offline start-path tests) — plus 4 appendix/seed items.
• 3 new findings: PROJ-022 (LOW — reserved UpstreamPlatformAddresses stub, deferred to upstream nonce reader), PROJ-023 (LOW — pre-existing error-string parsing in add_contact_screen.rs, tracked under refactor: migrate from Result<T, String> to typed errors with TaskError #660), PROJ-024 (BLOCKED-BY-DESIGN — check_address_usage).
• Merge-blocker verdict: no CRITICAL open. Sole remaining blocker is PROJ-005 (HIGH) — platform pin is an unreleased dev rev (this bump keeps us on ffdc28b8, so G1 release gate stands until #3625 merges and a tag cuts).

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

Dead-code cleanup + gap-audit reconciliation

Pushed 2 commits (419ef952..b2febb71).

9529aeda — refactor(dashpay): remove dead add_contact/remove_contact stubs + orphaned NotSupported variant (PROJ-002)

• The two free functions in src/backend_task/dashpay/contacts.rs were orphans from PR feat: HD wallet system, DashPay integration, SPV support, and more #464 (82399a26) — zero call sites, superseded by DashPayTask::SendContactRequest. Removed both, plus the now-constructorless DashPayError::NotSupported variant (errors.rs). 35 deletions.
• Verified the unrelated profile_search.rs::add_contact UI method is a distinct symbol (left intact). No dead imports left behind; clippy -D warnings clean.

b2febb71 — docs(gap-audit): resolve PROJ-002, re-file PROJ-012

• PROJ-002 → RESOLVED (removed).
• PROJ-012 re-filed from "deferred-by-design (LOW)" to functional gap (MEDIUM — OPEN). It was masking a real wiring bug behind #[allow(dead_code)]: the ZMQ status sender is live (app.rs:819) but rx_zmq_status is never drained and ConnectionStatus::set_zmq_status (connection_status.rs:159) has zero callers — so ZMQ connection-health events flow into a void and the status indicator never reflects ZMQ state. Binary fix: wire the receiver → set_zmq_status, or remove the whole producer→channel→setter chain (the channel pair is built as a unit at context/mod.rs:161, so no piecemeal trim).
• Also reconciled the executive-summary tally (it didn't sum before): now an honest 23 total / 17 open / 6 resolved.

Net: open-gap count holds at 17, but the audit books are accurate and a previously-hidden wiring defect (PROJ-012) is now surfaced as a real finding.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

Seedless wallet rehydration (PROJ-010) + platform → PR #3692

Pushed 5 commits (b2febb71..e6c6c017). Headline is the wallet-load re-wire.

f35ea7b9 — chore(deps): platform → PR #3692 head ddfa66ed

• All four platform crates re-pinned to feat(platform-wallet): load watch-only wallet state from local storage at startup platform#3692 head (feat/platform-wallet-rehydration). Verified ahead 59 / behind 0 of the prior pin (ffdc28b8) — a clean superset, MERGEABLE. Bare switch needed only one new fail-closed match arm (RehydrationTopologyUnsupported); the rehydration API is additive.

e6c6c017 — feat(wallet): seedless wallet load via UpstreamFromPersisted (PROJ-010)

• Closes the reserved G2 swap-point. PersistedWalletLoader reshaped to a seedless async load() -> LoadedWallets; UpstreamFromPersisted drives upstream PlatformWalletManager::load_from_persistor() (rebuilds wallets watch-only, no seed in memory at load). SeedReregistrationLoader deleted.
• Two deviations from the design, both forced by upstream crypto reality:
  1. Bridge matches on the BIP44 account xpub, not WalletId — upstream WalletId = SHA256(root_xpub‖chaincode) is depth-0 master, but DET persists the depth-3 account xpub, and you can't derive a parent from a child. The account xpub is the literal scanned==published routing key, so this is a stronger, migration-free guard.
  2. Identity-funding re-provision deferred to the post-unlock asset-lock chokepoint — a watch-only loaded wallet has no private key, so add_account can't run at load.
• Fund-safety gates: (1) account-xpub-match gate rejects any loaded wallet not matching a DET sidecar (preserves fund routing); (2) seed supplied only at unlock via provide_seed (signing keeps working; load stays seedless).
• 612 lib tests pass, clippy -D warnings clean. Fund-safety review by Smythe is in flight.
• Deferred: skipped-wallet MessageBanner (PROJ-010-T6) — skips are logged + returned in LoadedWallets.skipped, no UI surfacing yet (load path has no egui ctx).

Planning docs (rode along): rehydration design (df38b316), and Phase 1 of the sign-time unlock prompt feature — requirements+UX (d6811732) and a 45-case test spec (bf939c69).

Note: PR #3692 is an open, unreleased dev branch — this keeps the G1 release gate (PROJ-005) open by design until it merges and a tag cuts.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

Fix: no-password hydrated wallets couldn't sign (Smythe SEC-001/002)

2272bae0 — fixes a HIGH fund-signing bug Smythe found in the seedless re-wire.

Symptom: after the seedless rehydration, a no-password HD wallet hydrated as Open and the UI showed "unlocked," but inner.seeds was never populated — so signer_for returned WalletLocked for send / asset-lock / identity register+top-up. Inconsistent: DashPay/shielded (which read the seed off the Wallet struct) kept working, masking it.

Root cause: seeds reach inner.seeds only via the handle_wallet_unlocked → provide_seed chokepoint, which the no-password unlock paths bypassed; and bootstrap_loaded_wallets ran at AppContext::new (pre-wiring, empty wallet map) — a no-op.

Fix (one chokepoint, every path funnels through it):

• Re-timed bootstrap_loaded_wallets to the tail of ensure_wallet_backend (after hydration, populated map).
• Routed both no-password UI unlock paths (try_open_wallet_no_password, should_ask_for_password) through handle_wallet_unlocked.
• 33 call sites threaded &self.app_context (mechanical).
• Regression test (no_password_wallet_resignable_via_unlock_chokepoint): reproduces the seedless cold-boot state, asserts WalletLocked before, signing after.

The account-xpub fund-routing gate and seedless load path are untouched. 613 lib tests pass, clippy clean. Smythe re-verify in flight.

Separate pre-existing item (not from this change): the kittest suite has 15 Migration DivergentVersion failures from a stale on-disk migration artifact — verified identical on the clean base. Needs its own test-isolation cleanup.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

JIT secret-access refactor — HD seed no longer parked in memory (R3 complete)

Pushed 24 commits (2272bae0..43f412cf). This replaces the upfront session-long wallet-unlock model with just-in-time secret access: the HD seed is fetched, used, and zeroized within an operation, never held for the session.

Core (ed06c019 → 06a4b92e)

• SecretAccess chokepoint — async with_secret / with_secret_session, keyed by SecretScope{HdSeed, SingleKey}, behind a UI-agnostic SecretPrompt seam (egui host via mpsc→oneshot drained on the frame loop; NullSecretPrompt → typed error for MCP/CLI).
• Residency: operation-scoped by default, opt-in "keep unlocked until I close the app" (RememberPolicy, boxed + Zeroizing, cleared on network switch / teardown). Timed-unlock variant modelled for the future (no GUI yet).
• All signing routed through DetSigner (HD/single-key) and DetPlatformSigner (all 6+ platform-signer SDK sites incl. shielded), each borrowing the seed inside the secret scope — byte-parity proven against an independent reference on Testnet + Mainnet.
• Identity-auth public keys memoized in AuthPubkeyCache (DET KV sidecar, public keys only — no DB migration / no DivergentVersion risk; the path is hardened to the leaf so xpub-only derivation is impossible).
• Capstone: WalletSeed::open reshaped to verify-not-park; OpenWalletSeed.seed field dropped; Wallet::seed_bytes() deleted. rg "\.seed_bytes()" src/ → ZERO (compile-gate proof).

QA (three independent passes)

• Security (Smythe): SHIP — 10/10 end-state gates; the only remaining plaintext-seed residencies are the three deliberate, sound ones (opt-in session cache, JIT single-key borrow, user-initiated DIP-15 QR). block_on on the shielded path confirmed deadlock-safe (off-UI-thread).
• Tests (Marvin): 676 lib + 83 kittest + 3 doc — green. Added the HD signer parity test (independent reference + pinned vector), reentrancy + open_no_password guards.
• Consistency (Adams): typed-error conventions, naming, MCP/CLI all clean.

Also (43f412cf) — QA-005: AppState kittests isolated onto a temp data dir (with_isolated_data_dir), eliminating the 14 pre-existing DivergentVersion failures and stopping tests from touching the real user data dir. kittest now 83/0.

CHANGELOG + user-story WAL-006 updated for the new unlock model.

Deferred/non-blocking: single-key send remains an upstream stub (the JIT machinery is wired and waiting). The G1 release gate stands — PR #3692 is still an unreleased dev rev.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

NEW since last push — Settings Disconnect fix + persister-gap marker + nonce-ownership upstream issue (dd5f4e7e…a067a747)

9b2aacbf + a067a747 — fix: the Settings/network "Disconnect" button now actually disconnects.
AppContext::stop_spv() was an inert stub — it only nudged a throttle timer via reset_timer(), so ConnectionStatus::overall_state() (the UI's single source of truth) never moved and the button did nothing observable. The click was wired correctly; the method was the half-finished path. Rewrote stop_spv as a real async disconnect mirroring Connect: flip indicator → Stopping, backend.shutdown().await, unwire the backend via new AppContext::take_wallet_backend() (the start latch is one-shot, so the next Connect rebuilds a fresh, restartable backend), then settle Stopped/Disconnected and recompute state. The button now returns AppAction::StopSpv, dispatched off the frame thread symmetric with StartSpv. A single-winner atomic ConnectionStatus::begin_spv_stop() CAS closes a double-click window — the button disables on the click frame and a second dispatch loses the CAS, so no concurrent teardown. No String error fields, no new user-facing strings; ConnectionStatus stays the single source of truth.

QA (Marvin): both specs PASS, all hard regressions clean (no dangling backend Arc, reconnect rebuilds fresh, self-ban path stays closed, network-switch slots intact). Two LOWs he raised are closed in a067a747 (the synchronous double-click guard + a reconnect-rebuild test). 7 targeted tests pass; clippy -D warnings / +nightly fmt --check / build --all-features green.

1e19f46d — docs(wallet-backend): mark the missing core_derived_addresses seeding (utxo_address_not_derived).
Production-log triage surfaced a persister fatal-flush loop (173× across 7 wallets). The upstream rs-platform-wallet sqlite persister keeps two disjoint address tables — account_address_pools (written at registration) and core_derived_addresses (the UTXO writer's lookup, fed only by live addresses_derived events). On a genesis-rescan boot, SPV matches historical UTXOs at registered/watched addresses before their derive-event lands → UtxoAddressNotDerived → classified fatal → the whole buffered changeset is dropped → core_bridge re-emits → loop → receive/change balances under-report. Added an in-code TODO at the post-registration chokepoint; the upstream fix (seed core_derived_addresses from registration pools + narrow the buffer-wipe blast radius) is tracked separately.

dd5f4e7e…710df51f — docs(platform-wallet): upstream nonce-ownership issue draft.
Drafted and filed dashpay/platform#3825 (rs-platform-wallet should own and expose the per-address platform nonce: advance-on-submit + local reader), privacy-led, with the DAPI request-count claim corrected to one avoidable request per spend.

Merge-gate update (G1 / PROJ-005): upstream #3625 is now MERGED (6fa4686), and a tagged pre-release v4.0.0-beta.4 contains the persister crate — but re-pinning to it is verified UNSAFE. beta.4 ships only the bare squash-merge whose production load() is the deferred stub (persister.rs returns wallets_rehydrated=0), while the current pin 9e1248c carries the full rehydration stack (un-gate-schema-readers fix, per-account reconstruction, secrets, the wallet_meta → wallets rename). A swap would compile but silently no-op wallet rehydration and shift the on-disk schema. The pin stays at 9e1248c; G1 remains BLOCKED until a tag is cut from a master line that includes the rehydration stack.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

NEW since last push — re-pin to dashpay/platform#3828: persister-loop fix + Orchard security patch + shielded-API port (4247c360, a0d5034a)

Re-pinned all four dashpay/platform git deps from rev 9e1248c to 4f432c9 (the head of dashpay/platform#3828). This single bump lands three things:

1. Fixes the persister fatal-flush loop. #3828 is the upstream fix for the utxo_address_not_derived loop observed in production det.log (173× across 7 wallets): apply_pools now mirrors registration pool addresses into core_derived_addresses, load() additively backfills already-persisted DBs, and the flush blast-radius is contained (a single undeclared UTXO is skipped, not the whole changeset). The DET-side TODO marker added in 1e19f46d is removed — the gap is closed upstream. Verified at the pinned source: load() is the real rehydration path (wallets_rehydrated = len), not the beta.4-tag deferred stub.

2. Patches a live shielded double-spend vulnerability. The bump carries Orchard 0.13.1 → 0.14.0 and halo2_gadgets 0.4 → 0.5.0 — the patched versions for the disclosed Orchard counterfeit/double-spend flaw (the one behind Zcash's recent emergency hard fork). Smythe confirmed the copy_advice base-tying fix is present in the new halo2_gadgets.

3. Hardens the secrets vault at rest. beta.4's persister refuses to open a vault whose parent dir is group/other-writable (InsecureParentDir). DET's open_secret_store now chmod 0700s the secrets dir right after creation — every vault open routes through that one chokepoint, so this is both real at-rest hardening and what keeps the suite green on a default-umask runner (no harness/CI hack).

Shielded/SDK API port (the cost of the bump). 4f432c9 is a newer upstream lineage, so DET's shielded code was ported to the new signatures: shielded builders now return (StateTransition, Credits) and drop the explicit fee arg; the removed sync_nullifiers API → scan-based spend detection (collect scanned-action nullifiers, flip owned notes whose nullifier matches — a line-for-line port of upstream apply_scanned_nullifier_spends); compute_minimum_shielded_fee now returns Result, propagated via a new typed TaskError::ShieldedFeeComputationFailed; shield_from_asset_lock gained surplus_output.

QA — both SHIP. Smythe (funds/privacy): nullifier rewrite correct, no lockout, no under-fee. Marvin (correctness): the 84 lib-test failures under default perms were 100% beta.4 env-hardening (closed by the chmod 0700), the one AlreadyOpen was test-only (the production Disconnect→Connect path correctly drops the backend before reconnect), no port regressions. 779 lib tests pass / 0 fail on a normal runner; clippy -D warnings / fmt clean.

Merge gate (G1 / PROJ-005) — still blocks merge. The pin advanced and is materially better, but 4f432c9 is a PR head, not a tagged release. #860 still must not merge until #3828 merges upstream and a tag is cut from a master line that carries the rehydration stack. Non-blocking follow-ups tracked: a testable seam + unit test for the nullifier spend-match, dual-cursor unification, and the remaining sync.rs chunk-size literal.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

NEW since last push — fix PROJ-028/030 nullifier-cursor regression + v0.10-dev feature-parity audit (39433dac, 96558917)

Fix: shielded nullifier-cursor reset on migration + resync (PROJ-028 HIGH, PROJ-030 MED)

A regression introduced earlier in this branch by the #3828 re-pin (4247c360): the re-pin made nullifier-spend detection scan-based, keyed off a note-tree position cursor (last_nullifier_sync_height) — but pre-#3828 that persisted value was a platform block height, and the finish-unwire migration carried it verbatim. A migrated wallet therefore started its scan past the note-tree tip → spent notes never flipped → balance silently overstated, spends fail. Caught by a v0.10-dev parity pass against migrated (not fresh) state — the isolated #3828 port QA had reviewed fresh state only.

• PROJ-028 (finish_unwire.rs:730-738): migration now writes the cursor as (0,0) instead of carrying the legacy value, so migrated wallets rescan [0, tip] and correctly re-derive the spent set.
• PROJ-030 (shielded_tab.rs): "Resync Notes" now also resets the cursor (via delete_shielded_wallet_meta) so a resync truly re-derives spends instead of resurrecting spent notes.
• SEC-001 (model/wallet/shielded.rs:98): rewrote the stale "Block height" doc comment that caused the confusion — the field is now documented unambiguously as a note-tree position.
• TC-SH-002 renamed to assert the reset (the old assertion encoded the bug) + 2 new tests (migrated-cursor→scan flips spent note; resync resets). Full suite green (781+).

QA — Smythe SHIP (funds-safe): the from-0 scan accumulates every on-chain note (can't miss a spend) and is set-only (can't re-credit); delete_shielded_wallet_meta is cursor-only (notes dropped + re-fetched separately, transient balance errs understating); the note-sync cursor is tree-derived and carries no block-height hazard.

v0.10-dev feature-parity audit → docs/ai-design/2026-06-01-pr860-gap-audit/

Audited every user-facing feature in the pre-rewrite line v0.10-dev (≈ v1.0-dev) against this PR via four parallel domain passes + consolidation. gaps.md refreshed (now 28 open / 15 resolved; 0 CRITICAL · 3 HIGH · 10 MEDIUM · 15 LOW) and a schema-validated gaps-report.json added (v3.0.0 review-report format, /triage-findings-ready).

The audit surfaced several regressions the prior audit missed. Beyond the now-fixed PROJ-028/030, the open HIGHs are:

• PROJ-026 — Create-Asset-Lock QR funding flow soft-locks at "Waiting for funds…" forever: the only WaitingOnFunds→FundsReceived transition fires on CoreItem::ReceivedAvailableUTXOTransaction, which has zero producers. User sends DASH, it lands via SPV, the screen never completes.
• PROJ-027 — incoming DashPay contact payments never detected/credited (all networks): process_incoming_payment/register_dashpay_contact have zero callers; the v0.10 ZMQ detection path was deleted without replacement.

Plus ~10 MEDIUM (Send-Max always errors from a Core wallet; shield-from-Core ignores the chosen source address; settings reset on upgrade; Dash-Qt launcher unreachable; DashPay history/nicknames not migrated) and doc gaps (RPC-removal CHANGELOG sweep; removed Proof-Log screen). All catalogued with file:line in gaps.md and triage-ready in gaps-report.json.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

I checked the asset-lock recovery angle from the JS SDK discussion.

The identity paths look correct in this PR: src/backend_task/identity/register_identity.rs and src/backend_task/identity/top_up_identity.rs route wallet-funded and existing-lock flows through upstream IdentityWallet::*_with_funding with AssetLockFunding::FromWalletBalance / FromExistingAssetLock, so upstream owns tracking, resume, IS→CL fallback, submit, and consume cleanup.

But I do not think PR 860 fully handles the same issue for the non-identity asset-lock flows yet:

• src/backend_task/wallet/fund_platform_address_from_wallet_utxos.rs creates a tracked proof via WalletBackend::create_asset_lock_proof(...), then manually calls SDK outputs.top_up(...).
• src/backend_task/wallet/fund_platform_address_from_asset_lock.rs pulls a tracked proof from list_tracked_asset_locks(...), then manually calls SDK outputs.top_up(...).
• src/backend_task/shielded/bundle.rs creates a tracked proof via create_asset_lock_proof(...), then manually builds/broadcasts ShieldFromAssetLock; after broadcast it treats wait_for_response failure as only a warning.

Those manual paths bypass the upstream rs-platform-wallet higher-level orchestration that exists for this exact lifecycle (PlatformAddressWallet::fund_from_asset_lock, ShieldedWallet::shielded_fund_from_asset_lock, or equivalent): submit_with_cl_height_retry, IS-proof-invalid → CL-proof upgrade, proof/status persistence before retry, post-success balance/activity bookkeeping, and consume_asset_lock cleanup.

So the fresh asset-lock transaction itself is tracked better than JS SDK, but these DET call sites still have a post-asset-lock / pre-final-accounting gap: Platform submit failures or confirmation ambiguity can leave a valid tracked lock in an intermediate/reusable state, and successful submits are not consistently marked Consumed. That is not the same “lost one-time private key forever” failure as JS SDK, but it is still an incomplete recovery/resume implementation for asset-lock-funded Platform address and shielded flows.

Suggested fix: route these non-identity flows through the upstream wallet orchestrators, or mirror the same orchestration locally: resume/upgrade tracked proof, submit_with_cl_height_retry, persist any CL upgrade before retry, and mark the asset lock Consumed only after Platform acceptance/accounting succeeds.

Verified your analysis against current source — it holds. Here's how PR #860 now addresses it.

Shielded asset-lock flow (shield_from_asset_lock, src/backend_task/shielded/bundle.rs) — fixed. You correctly identified the real fund-safety bug: a wait_for_response failure after a successful broadcast was swallowed (warn! + .ok()) and fell through to Ok(credits) — a false success on a single-use asset lock. It now maps to a dedicated typed TaskError::ShieldedConfirmationUnknown (#[source]-chained, with an actionable, jargon-free user message) and is propagated, so an ambiguous confirmation can never report success. Two new offline tests cover the mapping and the message.

Platform-address flows (fund_platform_address_from_wallet_utxos.rs, fund_platform_address_from_asset_lock.rs) — no false-success; consume/retry orchestration deferred (upstream-gated). We traced both: the manual outputs.top_up(...) calls are ?-propagated through upstream broadcast_and_wait, so a submit/confirmation failure already surfaces as an error — no false success. What's missing is the terminal orchestration you named — submit_with_cl_height_retry, IS→CL proof upgrade, and marking the lock Consumed. Routing through PlatformAddressWallet::fund_from_asset_lock / PlatformWallet::shielded_fund_from_asset_lock is not possible from DET at the pinned rev: PlatformAddressWallet isn't re-exported, and submit_with_cl_height_retry / consume_asset_lock are pub(crate). Residual risk is a tracked asset lock left in a reusable/recoverable state on ambiguous failure — recoverable, not lost funds. Precise in-code TODOs naming the required upstream symbols sit at each choicepoint.

Also surfaced by review: the four sibling shielded spend fns (shield_credits / shielded_transfer / unshield_credits / shielded_withdrawal) swallow the same way and mark notes spent pre-confirmation — but that self-heals on the next nullifier/note resync (check_nullifiers reconciles against chain), so it's a temporary local divergence, not note loss.

All tracked in docs/ai-design/2026-06-01-pr860-gap-audit/ as PROJ-042 (this gap; shield false-success resolved in-PR, platform-address consume orchestration OPEN pending upstream API exposure) and PROJ-043 (the sibling-swallow follow-up). Verified by funds-safety (SHIP) and correctness (PASS) review passes.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

Correction to my earlier reply. I previously said the platform-address consume/retry orchestration was upstream-gated and not possible from DET. That was wrong — it is reachable through the public PlatformWallet API with no upstream change, and it's now implemented in this PR.

What landed (pushed):

• WalletBackend::fund_platform_address routes wallet-owned platform-address asset-lock funding through the upstream orchestrator PlatformAddressWallet::fund_from_asset_lock — i.e. resolve → submit_with_cl_height_retry → IS→CL fallback → consume_asset_lock. This closes the recovery gap you flagged for the common (wallet-owned) case.
• The orchestrator-vs-manual decision queries upstream's own pool membership (contains_platform_address) rather than any DET-side heuristic: a wallet-owned, in-pool destination gets full orchestrated recovery; a foreign/non-pool destination intentionally keeps the manual top_up path (advanced users may knowingly fund any address). Both paths propagate submit failures — no false success.
• The shielded asset-lock false-success is fixed separately (typed ShieldedConfirmationUnknown, no longer swallowed).

Commits: 37c2889e (shield), 1010828c (orchestrated routing), c45ac35e (upstream pool-membership gate). Verified by funds-safety + correctness review. Remaining residuals are tracked in docs/ai-design/2026-06-01-pr860-gap-audit/ — PROJ-042 resolved; PROJ-043 (a self-healing sibling-swallow in the four shielded spend paths) and a minor fee-from-wallet change-recipient case are being addressed as follow-ups.

Thanks for the catch — your read on the recovery gap was correct, and so was the implication that DET should route through the upstream orchestration.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

Two reliability fixes from live testing — crash visibility + DAPI ban storm (3c61a656…64632628)

Pushed 5 commits (dd3c390c..64632628). Both surfaced during fresh-boot testing on testnet.

Issue B — silent crashes now leave a trace (3c61a656, 96b61da7). The app could quit with nothing in det.log (a GUI launch loses stderr, and the Rust panic hook only catches catchable panics — native SIGSEGV/SIGABRT/abort/OOM vanish). Added: capture_stderr_to_file() (redirects fd 2 to a sidecar det-stderr.log, rotated, with a guard that no-ops when the logger already fell back to stderr) and install_fatal_signal_handler() (async-signal-safe write of a per-signal marker for SIGSEGV/SIGABRT/SIGBUS/SIGILL/SIGFPE, then re-raises so the core dump is preserved). Unix implemented + verified (abort/segv captured); Windows is a documented warn+TODO.

Issue A — Platform/identity sync no longer bans every DAPI node during initial sync (f318c06f, 9d5c865b). Root cause: sync started immediately at boot and issued proof-verifying DAPI calls before SPV had the masternode list → the context provider failed → the SDK's ban_failed_address banned all ~156 nodes (no available addresses). Fix: a CoordinatorGate (one-shot, single-winner latch) defers the platform/identity coordinator starts until the masternode list reaches Synced (which happens right after headers, well before the slow filter/block scan — so Platform still comes up early), driven event-driven from EventBridge; the SPV context provider returns a non-banning "not ready" error pre-quorum; the flag resets on disconnect/network-switch so a new session re-proves readiness. The gate captures Weak handles (a strong capture would pin the persister lock past teardown → AlreadyOpen on reconnect), with a dedicated regression test proven to catch a strong-capture revert.

QA: Smythe SHIP + Marvin PASS on both (gate proven never-strand + exactly-once; signal handler proven async-signal-safe). Consolidated tip: 987 tests pass / 0 fail, clippy + fmt clean. CHANGELOG updated.

Note: the platform pin is unchanged here (still the dev rev 4f432c9); the merge gate (re-pin to a tagged release) remains tracked separately.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

Re-pin platform deps to PR dashpay/platform#3828 branch (35f18be9)

Picks up the upstream merge that just landed on #3828 (the wallet-rehydration + core-derived-rehydration / persister fatal-flush-loop fixes). All four platform crates (dash-sdk, rs-sdk-trusted-context-provider, platform-wallet, platform-wallet-storage) re-pinned from rev = "4f432c9" to branch = "fix/wallet-core-derived-rehydration"; Cargo.lock locked to head 925dfcbf. Transitive rust-dashcore eb889af1 → 981e97f1.

Signature-only API port (behavior-preserving): shielded builders gained sender_ovk / dummy_outputs (DET passes None / 0 — byte-equivalent to the prior single-output form; surplus_output pre-existed as None); MasternodeNetInfo.service_address became a Legacy | Extended enum (UI display helpers with a non-routable fallback); two new PlatformWalletError variants (ShieldedBroadcastUnconfirmed / ShieldedSpendUnconfirmed) bucketed Other (do-not-resubmit).

QA — funds-safety SHIP, correctness PASS. Smythe verified the shielded-builder defaults are provably equivalent to prior behavior (recipient funds/spendability unaffected; surplus folds to fee pools, nothing stranded), and the rust-dashcore bump introduced no derivation/signing/quorum drift (bip32 signing + contains_platform_address byte-identical; the breaking network-scoped wallet_id change doesn't affect DET, which routes on the BIP44 account xpub, not wallet_id). Marvin confirmed the port is signature-only with an exhaustive error match, Issue A's masternode-readiness surface unchanged, and 987 tests pass / 0 fail, clippy + fmt clean.

Note: this is a branch = pin (a moving target) to track the in-flight upstream fix; Cargo.lock keeps today's build reproducible at 925dfcbf. The release merge gate still requires an immutable tag/rev before this PR merges.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

NEW since last push — 561bce8d WalletNotLoaded root-cause + upstream BIP32/BIP44 persistor-collision fix

Wallets failed to load on cold boot (WalletNotLoaded for every wallet, even on a fresh DB). Root cause: an upstream platform-wallet-storage primary-key collision. WalletAccountCreationOptions::Default creates both a BIP32 account-0 (m/0', depth-1) and a BIP44 account-0 (m/44'/coin'/0', depth-3), but account_type_db_label collapsed both to the single label "standard", so the two rows shared the account_registrations PK (wallet_id, "standard", 0). On persist, apply_registrations (INSERT…ON CONFLICT DO UPDATE) let the BIP32 depth-1 row overwrite the BIP44 depth-3 row — silently losing the BIP44 xpub. Cold-boot seedless reload then read the wrong depth-1 key and the fund-routing gate rejected every wallet.

Fixed upstream in platform PR #3828: the BIP32/BIP44 standard accounts now use distinct labels ("standard_bip32" / "standard_bip44"), so both rows coexist and BIP32 is preserved (users with legacy m/0' funds keep that account). This branch re-pins the platform crates to #3828 HEAD 925b109d.

• Re-pin platform crates 925dfcbf → 925b109d (Cargo.lock only; deps are branch-pinned). 561bce8d
• Regression guard: issue7_fresh_persistor_bip44_xpub_matches_det_bridge flipped from #[ignore] to a live test — it drives the real load_from_persistor_seedless cold-boot and asserts the stored BIP44 xpub is depth-3 and matches DET's bridge, and that the BIP32 row still survives (keep-BIP32 invariant).
• Terminal startup-failure notice (226db5fc): native startup failures now print a generic, actionable message plus log-file paths to the real terminal (stderr is redirected to a sidecar log), instead of exiting silently.
• The earlier #251 xpub-drift self-heal (9c45d7f3, b4668129) was investigated and reverted (89378d21) — it treated a symptom; the real cause is the upstream collision above.

Known limitation: there is no heal migration for DBs already corrupted by the old collision — those need a delete + re-import (the upstream PR treats the schema as unshipped). A follow-up protected-wallet-after-unlock registration fix is in progress (locked-at-boot wallets were not re-registered on unlock).

Suite green: 887 lib tests pass; fmt + clippy clean.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

Follow-up landed — 44caa892 register protected wallet on unlock

The "protected-wallet-after-unlock registration fix in progress" noted above is now in.

A password-protected wallet hydrates Closed (locked) at cold boot, so bootstrap_wallet_addresses_jit skips it on the is_open() gate (to avoid a surprise startup prompt) and it never enters the upstream fund-routing id_map. Previously the unlock gesture only promoted the verified seed into the session cache — it never re-drove registration — so a protected (or freshly migrated) wallet stayed WalletNotLoaded for the session and was skipped again on the next boot.

handle_wallet_unlocked now calls a new drive_unlock_registration, which spawns bootstrap_wallet_addresses_jit on a tracked subtask once the seed is session-cached → the wallet is upstream-registered prompt-free, no restart needed (seed promoted before the spawn ⇒ no second password prompt; the remember=false path is a no-op).

• Touches only src/context/wallet_lifecycle.rs.
• Test: protected_wallet_registers_upstream_on_unlock_without_restart — migration-faithful (legacy protected row → migration → hydrated Closed+unregistered → unlock → registered).
• Suite green (888 lib tests), fmt + clippy -D warnings clean.

This closes the remaining case after the #3828 re-pin (561bce8d): the re-pin fixes the persistor BIP32/BIP44 collision for fresh/unprotected wallets; this fixes the migrated-protected wallet whose upstream registration is empty at boot and can only be registered via the unlock path.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

NEW since last push — shielded backend retired in favour of upstream platform-wallet coordinator (f6373650…56ac2cfe)

Pushed 16 commits (44caa892..56ac2cfe). DET's home-grown Orchard shielded subsystem is removed and every shielded operation now routes through upstream platform-wallet's shielded coordinator. The bundle.rs:634 TODO(upstream-gated) was stale — the orchestrator is pub; the only real gate was the missing platform-wallet shielded cargo feature.

What landed (net −4,509 lines):

• Enable + wire the shielded feature; configure_shielded + ShieldedSyncManager lifecycle. (f6373650)
• WalletBackend op + bind methods wrapping the upstream ops (shielded_fund_from_asset_lock / shielded_shield_from_account / shielded_transfer_to / shielded_unshield_to / shielded_withdraw_to) with an exhaustive map_shielded_op_error — ShieldedSpendUnconfirmed can never report success. (caa443af, 18aa6ee2)
• Push balance snapshot: AppContext::shielded_balances written by EventBridge::on_shielded_sync_completed (maps upstream WalletId → WalletSeedHash), read synchronously in the egui frame loop — no block_in_place. Lazy bind via ensure_shielded_bound on JIT unlock. (7df68d78, 47c6eeba, fa0e46de)
• Deleted the 6 old shielded modules (context/shielded.rs, wallet_backend/shielded.rs, backend_task/shielded/{bundle,sync,nullifiers}.rs, database/shielded.rs, model/wallet/shielded.rs) + ShieldedTask reduction + a forward DROP TABLE migration + per-network legacy-file cleanup. (479c8c18)
• 5 new det-cli/MCP self-test tools: core_wallet_import, shielded_init, shielded_sync, shielded_balance_get, shielded_address_get. (63b2e796)

Also in this push (cleanups): module-placement policy added to CLAUDE.md + TrackedAssetLockCache → ui/state/; WalletUnlockPopup slimmed to a thin passphrase_modal wrapper; legacy ScreenWithWalletUnlock removed (migrated 3 screens). PROJ-032 closed as N/A (DashPay was never persisted in any released version — verified against v0.9.3); PROJ-034 confirmed real and tracked as a follow-up.

Verification: 874 lib + 88 kittest pass, clippy --all-features --all-targets clean (0 warnings), 3 build profiles green. A full grumpy-review (docs/ai-design/2026-06-16-pr860-grumpy-review/) found 0 critical / 0 high / 4 medium / 21 low; the medium + clear-low findings were fixed (56ac2cfe: mnemonic redact+zeroize in core_wallet_import, doc-accuracy, dead bind-guard, typed errors, stale-balance eviction, awaited coordinator wipe).

Open for reviewers:

• One MEDIUM left for discussion, not auto-changed: the typed passphrase is parked in a single global egui cache slot keyed by window title (password_input.rs) — possible cross-prompt leak; needs a UX-security call.
• Live testnet self-test of the shield→sync→transfer→unshield→withdraw loop via det-cli is recommended before merge.
• Merge remains gated on the upstream fix/wallet-core-derived-rehydration branch being released (the platform deps are pinned to it).

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

NEW since last push — 0484bcb6 post-migration identity auto-discovery (By-Wallet) + rolling gap-limit

Why: After the platform-wallet migration, a wallet's identities were only loaded if the user manually opened Load Identity → By Wallet and searched. This push discovers them automatically once Platform connectivity is ready, with a rolling gap-limit so newly-created identities are always found, and preserves user-set aliases on re-discovery.

What it does:

• Auto-discovery on Platform-ready. Once the SPV masternode list reaches Synced (the point at which Platform/DAPI is safe to query — querying earlier gets DAPI nodes banned), DET runs By-Wallet identity discovery across all open wallets. Two triggers: a global once-per-session sweep (AtomicBool latch, cleared on SPV stop so it re-arms on reconnect) and a per-wallet, latch-independent trigger fired when a wallet is unlocked.
• Rolling gap-limit (IDENTITY_GAP_LIMIT = 5). Scans to max(existing identity index) + 5, extending the window on each discovery so 5 empty indices always trail the highest found index (mirrors the BIP-44 address gap-limit). Bounded by a hard cap of 100. Pure decision logic in model/identity_discovery.rs (10 unit tests); one shared scan fn used by both the UI By-Wallet path and the auto-trigger.
• Alias preservation on re-discovery. Re-discovered identities are updated in place, but DET-only metadata (alias, wallet binding) is carried forward; top-ups are unaffected (stored under a separate key).

Safety items fixed in this push (surfaced by review):

• (High, pre-existing bug) the single-index By-Wallet search silently wiped a user's alias on every search — fixed (both single-index and gap-limit paths now carry the alias forward).
• (High, UX hazard) a background sweep over a locked protected wallet would have popped a passphrase modal unprompted (identity-auth keys are hardened-to-leaf, so a cold cache miss triggers a secret prompt); the background path now runs allow_prompt=false and skips locked wallets, and the eventual unlock re-triggers discovery for that wallet.

Verification: headless build clean · clippy -D warnings zero · 889 lib tests pass (4 new offline guards: latch one-shot + stop_spv re-arm, locked-wallet exclusion, alias preservation, search-index cap). Design + QA reports added under docs/ai-design/2026-06-17-identity-autodiscovery-gap-limit/.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

Session update — 5 commits pushed (d2f4fd87..1c4f4dcd)

Three fixes landed against the platform-wallet backend, each root-caused from a live testnet symptom:

Reconnect crash (09540cf8)

• Connect → disconnect → connect failed with WalletStorage(AlreadyOpen { … platform-wallet.sqlite }).
• Cause: WalletBackend::shutdown() never stopped the SPV run loop, so the persister path stayed registered in the process-global open-set.
• Fix: shutdown() now calls spv().stop().await before tearing down the wallet manager.

Watch-only asset-lock failure (98bc4913, tests b8517905 + acdd1336)

• Both "create identity" and "send funds core→identity" failed with AssetLockTransaction("Watch-only wallet has no private key").
• Cause: wallets reload seedless (watch-only); identity funding-account provisioning called add_account(type, None), which has no key material on a cold-booted watch-only wallet.
• Fix: provisioning now derives the account xpub from the seed (derive_extended_public_key) inside the with_secret_session scope and calls add_account(type, Some(xpub)). Regression guard uses a two-boot cold-start scenario (write persister from seed → copy data dir → cold-load seedless → assert provisioning succeeds + is idempotent).

Legacy MN-list-diff inspector + Core P2P handler removed (1c4f4dcd, −5,559 LOC)

• The Masternode-List-Diff inspector was the only RPC-only tool and is dead in SPV-only mode. Removed the screen (~4.5k LOC), core_p2p_handler.rs, MnListTask, TaskError::P2P, all wiring, and the backend-e2e mnlist tests.
• Verified independently: git grep clean of all removed symbols; surviving chainlock paths use only CoreTask::GetBestChainLock (no dependency on the removed task/handler).

Verification: cargo build (default + --features headless) ✅ · clippy --all-features --all-targets -D warnings ✅ zero · test --all-features --workspace ✅ 998 passed, 0 failed · +nightly fmt --check ✅ clean.

🤖 Generated with Claude Code

Pushed 1c4f4dcd..976ad0d4 (3 commits): backend-e2e coverage (B reconnect + C/D cold-boot), event-driven ensure_spv_synced (②), and the interim persister-release barrier for the reconnect AlreadyOpen regression (B-2).

The B-2 barrier is verified as an interim stopgap (closes the common coordinator-thread drain race). The durable fix — a reusable cancel + await-exit shutdown primitive (StructuredShutdown) covering both DET-owned wallet subtasks and the upstream coordinator threads, with the architecturally clean variant being keep-the-WalletBackend-alive + SPV/coordinator restart-in-place — is designed and will retire the barrier. An upstream rs-platform-wallet issue (make coordinator quiesce() join, not cancel-and-drain) will be filed. See the "Additional fixes folded in (2026-06-18)" section in the description.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

⛔ Blockers found — Sonnet deferred (commit 17f00d6)
Canonical validated blockers: 6