Refresh the EveryPay API reference against the current v4 spec

[acirtautas]

Summary

A field-level diff of docs/everypay-api.md against the current published v4 OpenAPI spec (support.every-pay.com/apidoc/main/openapi.yaml, still info.version: '4') surfaced a few things the distilled reference misstated or was missing. No payment states, endpoints, or required fields changed - the plugin's state mapper and request/response handling remain in sync with the spec.

• Correct the 2026-10 note: it is the billing/shipping character limits that shrink on 2026-10-01 (city/line1 50, postcode 16, country strict ISO alpha-2, billing_state ISO 3166-2), and omitting the fields for card payments risks higher decline rates / degraded fraud screening / limited dispute resolution - not "card limits".
• Add phone_number {country_code, number} and note that email + phone are flagged "soon mandatory for all card payment requests" (upcoming Visa/Mastercard requirements).
• Add order_reference length caps (255 card / 120 Open Banking) and the structured_reference Open Banking field.
• Mention PayPal, now an officially documented method on the hosted page.
• Document detailed=true on the status query (detailed_fraud_check_results).
• Enumerate the full event_name list (fraud + dispute events, token events) including the status_update / status_updated confusable and its acquiring_completed_at companion field.
• Add the token-related oneoff extras (request_token, token_agreement, token_consent_agreed, zero-amount card save) - groundwork for the tokenization roadmap item.

A follow-up PR adds the defensive truncation of address fields to the new 2026-10-01 limits in EveryPayOneOffPayloadFactory.

🤖 Generated with Claude Code