a rescan can be told how deep to look, and a node wallet cannot be deleted blind

the gap limit was 1000, hardcoded, with the comment noting that raising it costs
node CPU and not correctness — and no way to raise it. it is the one thing about
a scan only the owner can know: how many addresses their old wallet handed out
and never had paid. RescanOptions threads from the POST body through the backend
and the source to utxos/scan, capped at 100k because past that the scan takes
longer than anyone waits. the card gets a "search depth" field beside the button,
blank meaning the default.

deleting a wallet with no seed took one unconfirmed request. the dialog asked for
the wallet's name and then threw the answer away, so the check existed only for
whoever went through the dialog — a node wallet still holds the credential, the
labels and the freezes. confirmName now travels with the request and the route
enforces it. a bodyless DELETE is told which field is missing rather than that
its JSON did not parse.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/servers/sidecar/wallet/chain-source.ts

@@ -16,7 +16,7 @@
 // about which addresses are the wallet's, which is the kind of bug that loses coins rather than failing.
 
 import type { SpendableUtxo } from './psbt';
-import type { AddressType, FeeEstimates, OnchainTx, RescanState } from './types';
+import type { AddressType, FeeEstimates, OnchainTx, RescanOptions, RescanState } from './types';
 
 /** BIP44 chain index: 0 is the receive chain, 1 the internal (change) chain. */
 export type ChainIndex = 0 | 1;
@@ -132,11 +132,14 @@ export interface WalletChainSource {
    * Search the chain for this wallet's coins from scratch, rather than from whenever the upstream
    * started watching it. Returns immediately — a rescan takes minutes, and the caller is an HTTP route.
    *
+   * `opts.gapLimit` widens the search past the source's own default, for a wallet restored from one that
+   * issued addresses in bulk. Ignored by a source with no such knob.
+   *
    * Optional, and Esplora does not implement it — it has nothing to rescan, because a gap-limit walk
    * already asks about every address every time. This exists for an upstream that *indexes*, where a
    * newly registered account starts empty and stays empty until told to go and look.
    */
-  startRescan?(accounts: readonly ScanAccount[]): RescanHandle;
+  startRescan?(accounts: readonly ScanAccount[], opts?: RescanOptions): RescanHandle;
 
   /**
    * Find a scan already in flight upstream and return a handle to it, without starting one.