v4: match payment observations safely

[Phloraxx]

Scope

Sixth stacked PayGate v4 implementation slice. Depends on PR #47.

Implements

• apply one normalized Paytm/Kotak observation inside a short BEGIN IMMEDIATE SQLite transaction
• relay-event/package/source consistency checks
• durable payment_observations rows for matched, unmatched and ambiguous Activity
• exact profile + payable amount + historical reservation-window matching
• currently active collection profile is irrelevant to matching
• delayed trusted occurrence times may identify an older reservation after profile switches/reuse
• low-confidence Kotak notification_posted_at after exact-amount reuse fails closed as ambiguous
• server_received_at is treated as low-confidence after reuse
• cancelled payments match only when trusted occurrence time is at/before cancellation
• expired payments can become paid when occurrence time proves money arrived inside the protected reservation window
• duplicate relay-event processing is idempotent
• additional observations for an already-paid payment do not emit a second paid transition/webhook
• payer name/UPI enrichment remains separate from merchant name
• payment.paid history + webhook outbox + payment mutation + observation are atomic
• no UTR/RRN dependency and no network calls inside the DB transaction

Tests

Covers pending→paid, relay replay, duplicate observation for paid payment, delayed-after-expiry matching, before/after cancellation, reused-amount ambiguity for Kotak, trusted historical matching after reuse, and matching an older Paytm payment after new creation has switched to Kotak. Unit tests, race tests, vet and git diff --check pass locally.

Safety

No production HTTP or Android wiring yet. Unmatched/ambiguous observations do not mutate payment state.