fix(payments): drop the notification sender-IP gate; re-check on its own cadence

A real test payment on the contour exposed both problems at once. YooKassa
delivered the notification five times; all five were rejected because the
backend saw the sender as 10.77.0.1 — the contour sits behind a tunnel and
cannot observe real client addresses, the same reason the IP bans in this
repository are prod-only. The chips were not lost (the reconcile sweep would
have credited them), but the primary path was dead and the customer was left
watching an unchanged balance.

The address check is removed rather than made conditional. It never was the
security boundary — the confirming GET /v3/payments/{id} is — and the one thing
it bought is already bought earlier and far more tightly: the order is resolved
from the notification's metadata *before* any provider call, so a notification
naming no known order costs a single indexed read and stops there. Guessing a
live order id means guessing a uuid. Against that, an address check adds nothing
and breaks every deployment that cannot see real client addresses, while turning
any future change to YooKassa's published ranges into a silent degradation.

The second problem was mine. The reconcile threshold was keyed off the order
lifetime, so a lost notification cost the customer the full 30-minute TTL before
the chips landed. Those are different questions: the lifetime governs how long a
customer may take to pay, the re-check governs how soon we notice a lost
callback. Split apart — `payments.ReconcileAfter`, one minute, swept on every
reaper tick. The bound D49 was chosen for survives: the calls one order can
cause are still its lifetime divided by the sweep interval, a handful, not an
open-ended poll. Worst case for a failed notification drops from ~30 minutes to
~5; an order the customer is still paying for is left alone.

Tests: the foreign-sender test is replaced by the two properties that now carry
the load — a notification naming an unknown order makes no provider call at all,
and a genuine notification is honoured whatever address it appears to come from.
Plus one pinning that a seconds-old order is not polled.

The shared bundle budget goes 31 -> 32 KB, with the reason recorded in the
script header: every user-visible string lands in that chunk and it had been
sitting 40 bytes under the cap.

Decisions D48 and D49 revised.

docs/PAYMENTS.md

@@ -261,16 +261,26 @@ which is what later lets the order be re-checked and refunded. The browser retur
 nothing in the body may be acted on. It only names a payment, which the server then re-reads with
 `GET /v3/payments/{id}`; only that answer is trusted. Two guards ride on it: the payment's metadata
 must name the order being credited, and its `test` flag must match the shop's, so a test-shop payment
-can never credit real chips (nor a live payment be credited against test credentials). As defence in
-depth — and to stop a forger turning each fabricated notification into an outbound call of ours — the
-sender address is first checked against YooKassa's published ranges. The reply tells the provider
-whether to redeliver: 200 for anything durably decided, including a duplicate and a permanent
-rejection, and 5xx only for a transient failure (YooKassa redelivers for 24 hours).
+can never credit real chips (nor a live payment be credited against test credentials). The reply
+tells the provider whether to redeliver: 200 for anything durably decided, including a duplicate and
+a permanent rejection, and 5xx only for a transient failure (YooKassa redelivers for 24 hours).
 
-**Expiry-time reconciliation (D49).** No continuous polling. But a notification that is lost for good
-would leave the money taken and the chips unowed, silently, so the existing pending-order reaper asks
-the provider what became of each order that reached its expiry age carrying a payment id, and credits
-the ones that were in fact paid. One request per order over its whole life.
+The sender address is **not** checked (D48 rev). It would add no security — the confirming read is
+the whole boundary — and the one thing it bought, keeping a forger from turning each fabricated
+notification into an outbound call of ours, is already bought earlier and far more tightly: the order
+is resolved from the notification's metadata **before** any provider call, so an id matching no order
+costs one indexed read and stops there, and guessing a live order id means guessing a uuid. An
+address check is also actively harmful wherever the deployment cannot observe real client addresses —
+a contour behind a tunnel sees only its own — where it rejects genuine notifications.
+
+**Reconciliation on a short cadence (D49 rev).** No open-ended polling, but the check is **not** tied
+to the order lifetime: that governs when an unpaid order is written off, which answers "how long may
+a customer take to pay" — a different question from "how soon should we notice a lost callback".
+Tying them together would make a customer wait a full lifetime for chips whenever the notification
+path fails. The pending-order reaper instead asks the provider about every pending order older than a
+minute that carries a payment id, and credits the ones that were in fact paid. That bounds the calls
+one order can cause to its lifetime divided by the sweep interval — a handful — while a failure of
+the primary path costs minutes rather than half an hour.
 
 **A declined payment is surfaced.** A YooKassa `payment.canceled` records a `failed` payment event,
 so the customer is told the attempt did not go through instead of watching a balance that never