wallet: one quiet batch is not far enough to stop a restore

[Bitflash-sh]

Found while proving #109 with real coin, and it is a consequence of #109. A wallet could hold money that the phrase derives, that the phrase covers, and that restoring from the phrase does not find.

The failure, on a real wallet

The sequence that produced it — all on the live chain, current main:

1. -newphrase, then a payment from another node to -newaddress → lands on derived index 1
2. delete wallet.dat, -restorephrase → recovers it, and leaves nHDNext at 201
3. -sendto a 1 BTF spend → payment goes to index 201, change to index 302 (this is Keep HD change recoverable and bound message stalls #109 working: change is derived, not returned to an input's key)
4. delete wallet.dat, -restorephrase again:

  101 addresses checked, 1 transaction(s) recovered
  201 addresses checked, 1 transaction(s) recovered

Restored: 1 transaction(s) across 201 derived addresses

The spend is gone. Both the payment and the 4 BTF of change. -restoredepth=500 on the same wallet reported 2 transactions, which is what said this was reach and not loss.

Why

The loop stopped after the first batch of a hundred that turned up nothing, and the wallet digs a gap wider than that all by itself:

• a restore leaves nHDNext at the depth it scanned (201)
• the key pool then derives KEYPOOL_SIZE more (201–300)
• change takes the next index after those (302)

So the address used after a restore sits two hundred indices past the last one used before it, with nothing in between. The gap limit was smaller than the gap the wallet creates.

This is worse after #109, not before it. Change used to go back to an input's key — a low index the scan had already passed — so it was always found. Fixing the recoverability of change moved it out to where the scan stopped looking. One way to lose money traded for another.

The change

Three quiet batches instead of one. Same wallet, same chain, same phrase:

  301 addresses checked, 2 transaction(s) recovered
  ...
Restored: 2 transaction(s) across 601 derived addresses

What this does not fix

The gap is self-inflicted and it grows: each restore leaves nHDNext at the new scan depth, so the next spend sits further out than the last. A long enough history of restores can outrun any fixed number of quiet batches.

The structural answer is to pull nHDNext back to just past the highest index a transaction actually used, so the wallet stops digging. That is deliberately not in this PR: it rewinds a counter that hands out addresses, and it deserves its own testing rather than riding along with a fix that is already measured. Filed as the follow-up.

Testing

make tests passes. The before/after above is the same wallet with real coin on the live chain, restored twice.