Follow kessai: name a payment account by its uuid, and call it an account

kessai renamed the half of its contract that means payment account and had always said gateway, and then changed what that value is: an account is named by its uuid now, not by the machine name a site gave it. A name means whatever each site decided it means, which is no use to a payment read on the site that took it and on any site it was taken for.

See #3621937, merged.

Problem/Motivation

yoyaku_payment calls two methods kessai renamed: getAvailableGateways(), where the booking payment form offers the accounts a site can pay into, and isGatewayAvailable(), in the resolver's availability check. kessai deletes rather than deprecates before 1.0, so those calls, and everything else that named an account the old way, stop existing the moment kessai lands.

Proposed resolution

Follow the contract, and follow the value with it: what the tenant override, the site default and a booking action store is an account uuid, so the keys that hold them say so, and so does the resolver that answers with one.

What changes

• The call sites, so nothing fatals, and the words beside them: the site default is a Default payment account and the action's override a Payment account override.
• The stored keys move with the values they hold. yoyaku_payment.settings:default_gateway and the tenant's third-party setting of the same name become default_account_uuid; the booking action's gateway becomes account_uuid.
• PaymentGatewayResolver is PaymentAccountResolver, getGatewayForOrder() and getGatewayForTenant() are getAccountUuidForOrder() and getAccountUuidForTenant(), and the service is yoyaku_payment.account_resolver. What still says gateway means the gateway plugin, which is the one thing here that really is one.
• The resolver no longer falls back to manual. It answers empty when neither the tenant nor the site names an account this site can take a payment through, and the caller meets kessai's own refusal rather than a booking quietly recorded against a contract nobody picked — which is what kessai refuses to do for a consumer, and therefore what a consumer must not do for a site. A site that wants its bookings paid by hand picks the offline account kessai ships, the way it picks any other. That fallback was also already broken where it mattered most: kessai_engine ships the manual account, so a site taking its payments through a kessai elsewhere had no such account and the last step resolved to nothing.
• The booking action's override is chosen from a list rather than typed. Its help said to type the account's machine name; the value is a uuid, and nothing typed by hand is going to be one. A retired account stays on offer to the action that already names it, by kessai's shared rule, so the next save cannot silently move the money.
• The site-default field moved to the Booking settings form's own alter hook, where the placement, calendar and presentation modules already put theirs, and it has a test: nothing asserted it was there, so a hook that stopped firing would have taken the site's payment default with it in silence.

User interface changes

The site default is labelled "Default payment account", the booking action's override "Payment account override" and chosen from a list rather than typed, and a retired account shows as no longer available rather than disappearing.

API changes

PaymentGatewayResolverInterface is PaymentAccountResolverInterface, with both its methods renamed, and it answers the uuid of a payment account or empty.

Data model changes

default_gateway becomes default_account_uuid on both the site settings and the tenant third-party settings, and the booking action's gateway becomes account_uuid. All hold a uuid rather than a machine name.

No migration, and none is wanted: kessai is pre-1.0 alpha, so a site reinstalls rather than carrying an upgrade path that will never be used again.

AI-Generated: Yes (Claude Code was used to help draft this issue summary.)