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 in a workflow exported from one site and imported on another, nor to a payment settled by a kessai on another host.

See #3621937, merged.

Problem/Motivation

orchestra_payment calls getAvailableGateways() when the payment step builds its configuration form. kessai deletes rather than deprecates before 1.0, so that call, and everything else that named an account the old way, stops existing the moment kessai lands.

Proposed resolution

Follow the contract, and follow the value with it: what the step stores is an account uuid, so the key that holds it says so.

What changes

• The call sites, so nothing fatals, and the word beside them: the override is an Account override, because that is what it overrides.
• The stored key moves with the value it holds: gateway becomes account_uuid, the variable resolver's gateway_variable becomes account_variable, and the process variable it reads by default becomes payment_account_uuid.
• A retired account stays on offer to the step that already names it. An account is retired by being disabled and the list offers the enabled ones, so dropping it would show "use the resolver's account" for a step that overrides it — and a select posts what it displayed, so the next save of any setting on that form would make it true and the money would move to another contract because somebody opened a form. The rule and its wording are kessai's AccountOptions, shared so that three projects cannot drift.
• The variable resolver no longer falls back to manual when the workflow names no account. Choosing one would put the money in a contract the workflow never named, which is the thing kessai refuses to do for a consumer: its own contract calls an empty account list "a state worth showing rather than hiding behind a fallback".
• The example resolver charges through the first account the site holds, because no demo can know what a site called its accounts, and its docblock says what a real resolver does instead: take the account from what it is pricing.

User interface changes

The payment step's override is labelled "Account override" rather than "Gateway override", and shows an account a site has retired as no longer available rather than dropping it.

API changes

Payable::$gateway is $accountUuid, and holds the uuid of a payment account.

Data model changes

The step's stored gateway key becomes account_uuid and holds a uuid; the variable resolver's gateway_variable becomes account_variable.

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.)