feat(stripe): refunds, webhook retry sweep, and one-off settlement fix

[Tarunkumar0601]

Adds refunds from within ERPNext, makes failed webhooks self-heal, and ensures one-off Stripe payments settle into a refundable
Payment Entry.

• Refund via Stripe button on Stripe-originated Payment Entries (full/partial); charge.refunded records the refund as a comment (no
  auto credit note)
• Hourly sweep retries Failed webhook log events
• Settles the Payment Request as Administrator (the Guest checkout return / webhook can't read the Sales Invoice)
• Stamps the PaymentIntent onto the one-off Payment Entry so refunds work

Depends on feat/stripe-subscriptions.

Backport Needed: V15 & V16

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[greptile-apps]

Confidence Score: 4/5

The major correctness fixes all land correctly; the only new finding is a misleading audit-trail comment in process_refund.

All previously raised blocking issues appear addressed in this diff — permission check is present on refund_payment_entry, amounts are read server-side, handle_event elevates to Administrator before routing, and subscription sessions now resolve the first invoice PaymentIntent. The one new finding is that process_refund stamps the cumulative amount_refunded rather than the per-event refund amount, which misleads the audit comment for multiple partial refunds but does not affect financial correctness.

payments/payment_gateways/stripe_reconcile.py (process_refund cumulative amount comment)

_{Reviews (30): Last reviewed commit: "fix(stripe): settle payment request as a..." | Re-trigger Greptile}

[Karuppasamy923]

Could you please check this condition? As far as I understand, this endpoint is always accessed by a Guest user when the payment gateway redirects from the bank back to ERPNext. In that case, could you verify whether the mentioned permission check is actually required?