fix: two criticals in the previous round's fixes

A verification audit re-ran every fix and found two that were worse than what
they replaced.

The event-sum accounting scanned from `createdBlock`, but the baseline balance
is read at `latest`, which IS that block. Every transfer in it was counted
twice: once inside the baseline and once as a payment. A pre-funded address
whose funds arrived in the registration block confirmed instantly with nobody
having paid, which is exactly the bug the baseline exists to prevent, arriving
through the new path. Scanning starts at createdBlock + 1, and the received
figure is now the larger of the event sum and the balance delta, so a token
whose events do not match the filter falls back instead of reading zero.

`clearPending` blanked the stored record unconditionally while the in-memory
guard beside it was careful, so a `confirm` that threw with the word "invalid"
anywhere in its text erased the durable record of a payment that HAD been
broadcast. The next tab found nothing and paid again: the whole cross-tab guard
undone by one word of error text. It now refuses to clear a record that names a
transaction.

The pending marker also had no exit: any error outside a known pre-broadcast
list locked the payer out of the invoice forever. It now asks the merchant
first, and if they cannot see the money, hands the payer a distinct button that
says what it means, because only they can look in their wallet.

Also: cancel reads the chain instead of a cached field before writing money
off; cancelled is no longer deletable; the poll loop will not write back over a
row that changed under it; the receipt says when nothing actually checked the
payment; the honesty panel stays open under the receipt rather than collapsing;
three more documented confirm examples confirmed any HTTP 200.

115 tests, including the first coverage of event accounting, deadlines,
cancellation and the CSV carriage-return guard.

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