Keep funding payment records consistent across sync and classification

[jkczyz]

Funding broadcasts are classified into payment records off the broadcaster's queue, which runs concurrently with wallet sync — and can run after sync has already recorded the transaction, for instance when the counterparty's broadcast of a shared funding transaction is observed first. The two writers raced: a late classification could overwrite confirmation state that wallet sync had already advanced, sync could observe a half-written classification and record a duplicate generic payment, and graduation could roll back figures a concurrent classification had just written.

This makes each writer's decision and writes atomic against the others:

• Classification merges only the transaction type and our contribution figures into an existing record, leaving the confirmation state that wallet-sync events own in place. Once a record is confirmed, its txid and figures describe the candidate that actually confirmed and are kept on a late classification, except when the update names the confirmed txid itself.
• Wallet sync resolves a transaction to its funding record before deciding how to record it — including transactions known only as earlier RBF candidates — and serializes with classification's two-store write pair from that resolution through its final write.
• Graduation decides from the live record and updates only the payment status, so a stale snapshot cannot roll back concurrently written figures.
• A missing pending-store entry is recreated while the payment is still Pending, repairing the index after a crash or failed write between the two stores.

Raised by Codex in the review of #888 and hardened through subsequent review rounds.

Developed with assistance from Claude Code.