feat: payout ledger with bounded retry

Closes the gap the scheduler commit left open: a failed payday was retried
indefinitely with nothing but a log line to show for it.

Every attempt — paid, skipped and failed — is now written to
payroll.payouts and exposed at GET /api/v1/payouts. Failures are in the
ledger, not only in the log, because "why did nobody get paid on the 1st"
is the question the ledger exists to answer.

Ledger rows are self-describing: each copies the terms in force at the time
(amount, currency, both wallets) instead of pointing at the contract, and
there is no foreign key to contracts. A payout has to still read correctly
after its contract is edited, and deleting a contract must not take its
history with it. This is the one place duplicating a contract field is
right — the contract holds what is true now, a payout holds what was true
then.

Retries are bounded at 5 attempts per period, after which the contract is
paused rather than the period abandoned. A payday that cannot be funded is
a fact somebody has to act on; dropping it silently is the one outcome
payroll must never produce. Pausing does not advance the position, so
resuming after topping up retries the same payday. The attempt count is
derived from the ledger rather than a column on the contract, so it
survives a restart and stays auditable.

Also restores the explanatory comments on the broad `except Exception`
handlers, which ruff's RUF100 stripped along with their now-unused noqa
directives.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018jy52j9GRZ6XKa1Zt21LLj

docs/operations.md

@@ -56,6 +56,32 @@ payroll: contract a1b2c3d4 period 3 failed: insufficient balance in source
 wallet: 12000 sat available, 80000 sat required
 ```
 
+Retries are bounded. After `MAX_PERIOD_ATTEMPTS` (5) failures on the *same*
+period, the contract is **paused** and the operator has to act. Pausing
+rather than abandoning the period is the point: a payday that cannot be
+funded is a fact somebody needs to see, and silently dropping it is the one
+outcome payroll must never produce. Because pausing does not advance the
+position, resuming after topping up the source wallet retries that same
+payday.
+
+## The payout ledger
+
+Every attempt — paid, skipped *and* failed — is written to
+`payroll.payouts`. `GET /payroll/api/v1/payouts` returns them newest first,
+filterable by `contract_id` and `status`. "Why did nobody get paid on the
+1st" is the question the ledger exists to answer, which is why failures are
+in it rather than only in the log.
+
+Rows are self-describing: each one copies the terms in force at the time
+(amount, currency, both wallet ids) rather than pointing at the contract,
+so a payout still reads correctly after its contract is edited or deleted.
+There is deliberately no foreign key to `contracts` — deleting a contract
+must not take its history with it.
+
+The attempt counter is derived by counting a period's prior failures in the
+ledger, not from a column on the contract, so it survives a restart and the
+rows that produced the number are right there to audit.
+
 ## Back-dated start dates
 
 Creating a contract with a start date in the past is normally an