feat(dig-app): the DID wizard promises a re-entry point that does not exist

[MichaelTaylor3d]

Every failure screen in the first-run DID wizard (#2341) tells the user "open the DIG menu later and it will tell you".

Nothing backs that promise. No tray row watches a pending spend, and none offers to resume a mint. A person whose funding arrived late, or whose mint was still unconfirmed when they closed the wizard, has been told where to look and there is nothing there.

Why this is a dead end, not a gap

professional-ui's first HARD RULE is that a person must never be trapped, and #1800 removed exactly this shape — a message naming a next step that does not exist. An unbacked promise is worse than silence, because the user stops looking for another way.

It also blocks #2342 being usable: the mint is asynchronous by design (begin_did_mint → PendingMint → confirm), so "come back later" is the normal path, not the failure path. Without re-entry, the only way to complete a slow mint is to never close the window.

Scope

• A tray surface that knows a mint is pending and says so.
• A way to resume: re-open the wizard at the waiting step, or report the outcome if it resolved while the app was closed.
• The pending state must survive a restart — it is on-chain, so the evidence is recoverable, but the app has to know to look.

The related defect it must not inherit

The adversarial gate on dig-account PR #7 found that confirm returns Ok(None) forever for a permanently dead mint — mempool eviction, fee-too-low expiry, a reorg respending the source coin. A resume surface built on that API will offer to resume something that can never finish.

So this needs #2342's PendingMint to carry enough to answer "is this still possible?" — the gate suggested pushed_at_height plus a way to see the funding coin spent elsewhere. Do not build the re-entry point on an API that cannot say no.

Found by the #2341 implementation lane, which flagged its own unbacked promise.

Orchestrator ticket: https://github.com/DIG-Network/dig_ecosystem/issues/2398

Moved from DIG-Network/dig_ecosystem#2351 so this repo's own PR can close it with Closes (CLAUDE.md §1.3).
GitHub refuses a private-to-public issue transfer, so the body was copied and comment history
stayed on the original.

[MichaelTaylor3d]

Verification sweep 2026-08-20 — verdict: PARTIAL — the unbacked promise is FIXED and 3 of 4 scope items are merged; one surface is still missing

Measured against origin/main of DIG-Network/dig-app at 64656adb (v12.34.1).

The headline defect — the promise nothing backed — is FIXED (dig_ecosystem#2560)

The copy no longer points at the DIG menu, and the code records this exact defect and its remedy.
crates/dig-app-core/src/account/journey.rs:1759-1771:

/// The ONE re-entry route that exists, named in one place because five screens point at it.
///
/// # Why it does not say "from the DIG menu"
///
/// It used to, on five screens, and there is no such row: `TrayAction::AboutDid` is a notice
/// that cannot call the wizard, and the nearest menu rows to it —
/// `ReplaceWithNewAccount`, `ReplaceFromPhrase`, `RemoveAccount` — DESTROY the account. So the
/// one instruction given to somebody who declined pointed at losing their custody. What is
/// true instead is [`startup_wizard`]: while an enrolled account has no DID and this build can
/// mint, the wizard opens at the DID step on every launch (dig_ecosystem#2560).
pub const OFFERED_AGAIN: &str = concat!(
    "The DIG menu has no row that starts this. DIG offers this step itself, each time it ",
    "starts, for as long as your account has no DID — so you can do it whenever you are ready.",
);

The re-entry itself is journey.rs:947 pub fn startup_wizard(...), pinned by two tests:
journey.rs:3780 the_startup_wizard_opens_only_for_an_enrolled_account_that_can_still_mint (which
drives the whole cross-product of account state and mint availability) and journey.rs:3826 a_recorded_mint_is_what_turns_the_startup_wizard_off.

"Do not build the re-entry point on an API that cannot say no" — SATISFIED

The Ok(None)-forever defect this ticket warned about is gone. crates/dig-app-core/src/account/profile_mint.rs:490-536
carries the three coin facts and answers a three-valued liveness, using exactly the two signals the
adversarial gate suggested — pushed_at_height and the funding coin spent elsewhere:

struct InFlight {
    /// The coin the bundle consumes.
    funding_coin_id: Bytes32,
    /// The coin the bundle would create.
    created_coin_id: Bytes32,
    /// The chain's peak immediately before the push.
    pushed_at_height: u32,
}

        // The funding coin is gone and the coin it should have created never appeared: some other
        // spend consumed it, and this bundle can never be included.
        if let Some(spent_at) = funding.and_then(|record| record.spent_height) {
            return MintLiveness::ProvablyDead {
                evidence: DeathEvidence { ... },

liveness_of (profile_mint.rs:457) has a real production caller at profile_mint.rs:778
(liveness_of(self.session, self.target.ix(), self.chain)), not just tests.

"The pending state must survive a restart" — SATISFIED, and the funds-loss hazard it hid is closed

profile_mint.rs:546-551, verbatim:

/// # The restart-surviving guarantee this gains over [`ChainMint`](crate::account::chain_mint::ChainMint)
///
/// `ChainMint` refuses a second push from a `Mutex<Option<PendingMint>>`, which lives exactly as
/// long as the process: closing and reopening dig-app resets it and permits a second paid mint. Here
/// the refusal is `ProfileRegistry::begin_seeded_mint` declining a reserved index, and the registry
/// is PERSISTED — so the guard **survives a restart**.

What is STILL MISSING: "a tray surface that knows a mint is pending and says so"

The pending-with-a-growing-block-count surface exists — but only for a SEND, not for a mint.
crates/dig-app-core/src/confirm/gui/window/pane/wallet.rs:760-764:

            blocks_since_push, ..
...
            copy::wallet::send_pending_body(*blocks_since_push),

and crates/dig-app-core/src/tray_menu.rs:516-518 names why that field must repaint:

            // The Wallet pane RENDERS this, and every state it passes through is one a person is
            // waiting on: signing, then pending with a block count that grows, then confirmed.

TrayView carries mint_chain (a chain-READINESS reading, tray_menu.rs:506) but no pending-MINT
field, and MintLiveness — re-exported at crates/dig-app-core/src/account/mod.rs:77 — has no
consumer outside profile_mint.rs. So the machinery to answer "is my mint still coming?" exists and
correct, and nothing puts its answer in front of a person. That is the remaining work, and the send
card is the shape to copy.

Moving to DIG-Network/dig-app under https://github.com/DIG-Network/dig_ecosystem/issues/2398 —
the remaining item is one pane field plus one TrayView field, all dig-app-local.