Opening a payment, and applying its settlement.

Two operations and one invariant between them: money is never accepted
without what it bought being handed over, and what it bought is never handed
over twice. The store's pending -> paid transition is the gate — it is a
compare-and-set, so a redelivered notice, a poll that races a webhook, and a
retry after a crash all converge on exactly one fulfilment.

Settling from a notice a provider posted.

The rule the whole namespace exists to enforce: a notice NAMES an invoice,
and the invoice SELECTS the rail that must authenticate the notice. A caller
never chooses its own authenticator. The provider in the URL is a claim,
checked against the invoice; a body that names an invoice is a claim, and
granting on it directly is the vulnerability this shape removes.

Returns a verdict value, not a response: the boundary decides what an HTTP
status is.

Settlement by asking. A rail that cannot call the store must be polled, or
its invoices never settle at all — and a rail that can call is polled anyway,
because a webhook that was never delivered leaves money sitting in a wallet.

The poll drives the same `checkout/settle!` path a notice does, so a payment
seen twice still buys exactly one period.