Perform the rescan when adding a standalone address

[erubboli]

Problem

Adding a standalone address with a rescan (standalone-add-watch-only-address, standalone-add-private-key-from-hex, standalone-add-multisig, and the corresponding address_add_standalone_* RPC methods) calls reset_wallet_to_genesis() and nothing else. The actual rescan is left to the controller's background sync loop.

In wallet-cli non-interactive mode (--commands-file) the process exits as soon as the commands file is exhausted. That closes the wallet service command channel, and the worker's biased select cancels the in-flight sync before it makes any progress. So:

• The rescan never runs and the wallet is left at genesis. Every subsequent wallet-open then has to rescan the whole blockchain (on mainnet that is ~673k blocks, which is slow enough that users interrupt it and leave a stale SQLite journal behind).

• The teardown can surface a confusing error. If the sync did issue a node RPC call before the process tore down, the cancelled call is logged as:

  ERROR wallet_controller: Wallet sync error: Wallet sync error: Unexpected RPC error:
  Response error: Custom error: Error reason could not be found.
  This is a bug. Please open an issue.
  

  That string is jsonrpsee's placeholder for "the client's background connection task is gone and no disconnect reason was recorded" — i.e. the RPC client was dropped mid-request. Nothing is wrong on the node side, which is why the node logs are silent.

Reported for standalone-add-multisig on mainnet (v1.4.0, aarch64), but it affects all three commands. Cold mode is unaffected because no sync is attempted there.

Fix

Sync right after the reset, the same way wallet_rescan already does, so the rescan is complete by the time the command returns and the printed "Rescanning the blockchain to detect balance in added new addresses" is true.

Also skip the reset when the add itself failed, so e.g. a duplicate-address error no longer discards the wallet's scan state and forces a full rescan later.

Notes

• The command now blocks for the duration of the rescan. wallet-rescan already behaves this way, and --no-rescan true remains available for callers that do not want to wait. Note that over a remote wallet RPC daemon a long rescan can exceed the client's default 60s request timeout — that is pre-existing for wallet_rescan and is not addressed here.
• A better long-term fix is to not reset the wallet to genesis at all and scan for the newly added destination without moving the wallet's best block, so that an interrupted rescan costs nothing. Filed separately as Wallet: scan for a newly added standalone address without resetting the wallet to genesis #2106.

Testing

Reproduced on a local regtest chain (500 blocks): before the change the wallet is left at height 0 after standalone-add-multisig and the next open rescans the entire chain; after the change the rescan runs inline and the next open needs no sync at all. A failed (duplicate) add no longer resets the wallet.

Existing tests pass: cargo test -p wallet-rpc-lib, and the functional tests wallet_multisig_address.py, wallet_watch_address.py, wallet_list_utxos.py, wallet_htlc_spend.py, wallet_htlc_refund_multisig.py, wallet_tokens_transfer_from_multisig_addr.py.