0.3.7 — wallets, bank payments, and orders that unstick themselves

Wallets, bank payments, and three ways an order could get stuck. Everything below is on main from PRs #5–#13; this release tags and packages it for testing.

A wallet approval can no longer take money without an order. Apple Pay and Google Pay are available in the payment box again. A wallet sheet charges the instant the customer approves it — on their own tap, inside VezmoPay's form, before WooCommerce has an order for that money to belong to. The plugin now holds the approval, places the order, and only then lets the charge complete; a checkout WooCommerce refuses cancels the payment instead of taking it. The buttons stay greyed out until the required checkout fields are filled.

Bank (ACH) payments can be selected at checkout. The payment form is created for the cart before any billing field is filled, so it carried no customer — and an ACH debit mandate requires the payer's email, so choosing Bank simply failed. Billing details are now sent to VezmoPay as they are typed, on both checkouts, with the order's own billing attached as a backstop before anything is charged.

A submitted bank payment completes the order instead of stranding the customer: the order goes on hold with a note saying the debit is clearing, the customer reaches order-received, and the order updates itself when the debit settles. Pressing Place order again while that debit is on its way no longer starts a second payment.

The checkout no longer calls a payment failed while the store is completing it. Confirming an order sends its emails, which can take tens of seconds; everything asking about the payment in that window was told "still waiting", so the customer saw a failure and the order collected a "no result" note seconds before its own "payment captured" note.

A status check that never finished can no longer freeze an order permanently. An abandoned claim is broken after two minutes and logged, instead of turning away every later check, webhook and retry for that order forever.

Also: the "Check VezmoPay payment status" action stops reporting LOCKED as if it were a payment status; debug logging no longer writes a live payment credential (the secure-payment token travels in the request path, and only bodies were redacted); the payment frame pins a referrer policy; the settings form fields no longer recurse into init_settings; and a new Transaction label setting tells VezmoPay which store a payment came from.

Translation template regenerated (242 strings).

vezmopay-sha256: 889d5f30c77068077c75bc21a1ab2a7073be43084da3227390a947b79c6cc917