feat: improve wallet discovery and Yano mempool-aware sends

[satran004]

Restored Shelley wallets can miss funds when receive/change discovery stops at spent addresses, and subsequent sends can reuse confirmed inputs already claimed by a pending transaction. This PR improves address discovery and history recovery, and uses Yano's mempool-aware UTxO view for transaction building.

Changes

• Scan receive and change chains using first-seen address history; persist credential-filter transaction scans and recover canonical checkpoints after reorgs. Include withdrawable rewards in the dashboard total.
• Request include_mempool=true for Yano address/payment-credential selection listings and individual output resolution. Pending-spent inputs are excluded and pending change is eligible for ADA and native-asset sends, including hardware builders.
• Persist local submitted-input reservations and remember the exact input/owner reported by a Yano conflict. Discard conflicting drafts and offer Rebuild & review without automatically resubmitting a stale signed transaction.
• Preserve confirmed balance/history and existing CIP-30 UTxO queries. Yaci DevKit keeps its existing selection/submission backend and address-transaction history, without Yano scan or mempool requests.
• Show the year in transaction history and default Yaci DevKit connections to port 8080.
• CIP-30 multi-address signing (ADR-047). signTx/signData no longer sign only with receive index 0. A bounded search over the unlocked HD account finds the keys a request actually needs: session-known paths first, then receive/change 0–29, and 0–49 only after an explicit user extension. Targets come from required_signers and resolved spending/collateral inputs only. The approval prompt lists the matched paths and any unmatched hashes; a one-use ticket binds consent to the exact bytes, session and backend. Hardware signing is unchanged.
• Receive address details. Each receive address can show its payment and stake verification keys and key hashes with derivation paths (public material only). Viewing one also makes that path known to the signer search.
• Wallet scan feedback. The History screen reports a scan in flight instead of sitting empty: "Loading history…" immediately, then Scanning the chain for your transactions — block X of Y · N%, read from the ready/progress records the scan already streams. Progress is published unsynchronised (the scan holds the instance lock for its whole run) and cleared on every exit, so a failed scan leaves no frozen percentage; the poll runs on the common pool, never the backend executor the scan occupies. A node with no scan route and no local record now says "History not found" rather than "No transactions yet"; where local records exist they still show under the "Local history only" chip (ADR-043).
• Yano 0.1.0-pre16 and managed-node sizing. The node pin moves to pre16, which serves the wallet scan index. The managed node is spawned directly rather than through yano.sh, so it now gets that script's sizing itself: quarkus.profile=<network>,<sizing>,wallet (medium by default; wallet stays last so its index switches cannot be overridden) and the matching -Xmx (384m/384m/1536m/2g), placed before -jar so the JVM reads it. Both can be edited in ~/.yano-wallet/<network>/node/node.properties, written as a commented template beside node.log.
• Scan-index fallback. A node with the scan route but no usable index fell into a history error on every refresh. A 400 "outside complete filter coverage" on a scan from origin — what every chainstate upgraded from a pre-index node returns, because its index starts partway through the chain — now falls back to local history (ADR-043). From a saved cursor the same 400 can mean the index is briefly behind, so it stays an error. A 503 means "no history" only for UTxO state off, coverage.enabled: false, or a reason naming a fresh sync; temporary states (index behind the applied block, storage being replaced, the concurrency limit) stay errors rather than hiding real transactions.
• Retrying an uncertain submit. After a transport error or 5xx, the retry collided with the reservation its own first attempt left, was recorded as a conflict, and the payment was marked FAILED with its draft discarded — so if the first attempt had landed, a rebuild paid twice. Now the identical signed transaction may be resent (only a different transaction over reserved inputs is a conflict); before a 4xx releases inputs the wallet checks GET /txs/{hash} and reports a transaction already in a block as submitted; a failed check keeps the reservation and asks for a retry; and WalletService.submit treats only a 4xx as a rejection.

Validation

• ./gradlew :wallet-node-client:test :wallet-core:test :wallet-app:test :wallet-ui:test --console=plain passed. Tests cover ADA/token construction using pending change, pagination, credentials, reservation persistence/cleanup, conflicts and rebuilding, lookup failures, and explicit DevKit isolation.
• Read-only checks against the running preprod Yano at port 7070 verified an overlay-excluded confirmed input and a pending output with block: null, plus address, credential, address-as-credential, and single-output queries. No user transactions were submitted by these checks.
• Earlier discovery validation ran the opt-in WalletIndexLiveTest against both JVM and native Yano nodes, covering persisted assets/outpoints, outgoing-only history, fully spent addresses, restart/crash recovery, snapshot reorg recovery, and replacement transactions. Reproduction: docs/wallet-index-live-validation.md. Mainnet-scale history/performance measurements remain deferred.
• Signer search: DappSignerSearchTest (0/1/2 and change keys, 29/30/49/50 boundaries, known high indexes, account isolation, input vs output/reference ownership, pre-existing witness verification, stake keys, malformed/bounded requests) and Cip30SignerSearchApprovalTest (gate-to-signer wiring, extension accepted/declined, full vs partial sign, session/network/body changes, one-use tickets). Each new commit was also tested on its own: connector-host 24, core 192, app 73, ui 14 tests, all passing. Not yet qualified with a live extension session.
• Node pin, scan fallback and submit retry: NodeLaunchCommandTest/NodeOptionsTest (argument order, profile and heap from node.properties), WalletScanHistoryTest (400 from origin vs. saved cursor, each 503 reason), PendingInputsTest (resend after an unknown outcome, resend of a transaction already in a block, unverifiable refusal keeps its reservation, self-claimed conflict, a different transaction still refused) and SubmitOutcomeTest (5xx retryable with no FAILED record, 4xx FAILED). Run against the previous code, 6 of the new submit tests fail. Full run: core 194, node-client 121 (5 opt-in live tests skipped), app 73, launcher 44, all passing. Not yet exercised against a live node: the duplicate-returns-200 and out-of-coverage-400 behaviour is taken from the pre16 source.
• Scan feedback: ScanProgressTrackerTest (unknown tip before ready, resume-cursor interval, completion clearing progress, unreadable records, fraction bounds), WalletScanHistoryTest progress empty after both success and failure, and HistoryMessagesTest for the two empty-state messages and the progress line. Full run: connector-host 24, core 192, node-client 111 (5 opt-in live tests skipped), app 73, ui 17, all passing. The progress line itself has not been seen in the running app — an incremental scan completes in about 9 ms, so showing it needs a scan from origin.

Node dependency and limits

Yano selection requires the newly implemented include_mempool=true listing contract; confirmed-only fallback is not used on lookup failures. Runtime results remain transient, so local reservations and submission conflict handling are retained. There is no custom acknowledgement-header requirement.

The managed node is now pinned to Yano 0.1.0-pre16 (gradle.properties); the pre13 checksums stay in the lock file for an explicit -PyanoVersion override.

Reservations survive wallet restarts but are local to this wallet application. An externally learned conflict with unknown validity cannot currently be released on mempool eviction alone; confirmation clears it. See docs/mempool-coin-selection.md for refresh and failure semantics.

Known open issues

Reported by a code review of this branch and not addressed here; none has been re-verified yet:

• The pre-signing simulation counts fewer addresses as the wallet's own than the signer can sign for, so a dApp transaction spending a UTxO outside the gap-limited scan can under-report a loss (TxEffectSummariser). On upgraded chainstates an incomplete address scan also makes every simulation "could not be checked".
• A reservation with TTL 0 (a dApp transaction with no upper validity bound, or a learned conflict owner) is released only when the transaction reaches a block; if it is dropped, its inputs stay excluded from selection indefinitely.
• pending-inputs.json is not fsynced before its atomic rename; a truncated file after a crash prevents the wallet from connecting until it is deleted.
• The unlocked DefaultWallet caches accounts in an unsynchronised HashMap but is now used from the signer-search, simulation and dashboard threads.
• An unused address is accepted only once the first-seen index is at the live tip, so any lag makes the whole address scan — and with it balance, drafts and simulation — fail.
• CIP-30 getUtxos returns the confirmed view while signing resolves inputs through the selection view, so a dApp can build a transaction the wallet then refuses to sign; chained dApp transactions are refused too.
• The signer search no longer signs with the primary payment key by default and does not look inside native scripts, so a sponsored mint whose policy needs the wallet's key only via its script is refused.
• The Dashboard requests history every 5 s with no in-flight guard, queuing behind a long first scan on the single backend executor.
• Performance: every selection lookup refreshes reservations with network calls under a lock, and the simulation runs a full two-chain address scan inside its 3 s budget.
• node.properties: maxHeap accepts a bare number (bytes to the JVM) or 0, which stops the node at startup; the file is re-read on each accessor call rather than once per start.

Discovery work relates to bloxbean/yano#119; companion discovery/index node PR: bloxbean/yano#120.

🤖 Generated with Claude Code