payout: keep one retry clock, the one that is used, and persist it

There were two, and each was broken in the opposite direction.

PendingPayout::retryAfter was declared, serialised into pending_payouts.json,
loaded back, and tested at the flush gate -- and the only assignment to it
anywhere in the tree was `= 0`. The gate could never fire. PendingPayout's
`retries` and `deferrals` were the same: carried, never written. Dead fields
next to live ones in a structure this one is easy to reach for by mistake, and
a gate that looks like backoff but is not is worse than no gate at all.

PayingRecord::retryAfter is the clock the payout thread actually uses -- and
SavePayingLocked did not write it. Every restart therefore reset every
backing-off payment to "ready now" and put the entire in-flight set into the
very next 500 ms batch instead of once a minute. On a node restarting in a
loop that is a continuous retry storm against a wallet that has already said
no, each pass taking cs_main.

The dead copy is deleted, along with the flush gate that read it and the one
`retryAfter = 0` in RecordPayoutTxid. The live one is now persisted and
restored. Retry state stays where the failure happens -- per (round,
recipient), which is the granularity SendMoney works at.

On disk, both directions still read:
  - pending_payouts.json no longer has "retryAfter" written into it, and no
    longer reads one. Files that carry it (everything the merged build wrote,
    always as 0) load unchanged, the key simply ignored. A build that expects
    it defaults an absent key to 0, which is the only value it has ever held.
  - paying_payouts.json gains "retryAfter". Older builds ignore unknown keys;
    this build defaults an absent one to 0, which is exactly the behaviour a
    file written without it used to get.

0 files changed, 0 insertions, 0 deletions