Issue #3621928: Give payments an admin section of their own, and call a gateway instance a payment account

Closes #3621928 (closed).

What changes

A Payments section of its own, at /admin/payments, the shape core gives every administrative section: a menu-block page, and under it Accounts, the four listings, and Settings. /admin/config/services/kessai becomes /admin/payments/settings and the accounts collection becomes /admin/payments/accounts; the four view pages move with them. Nothing of this module is left under Configuration.

The config entity is a payment account throughout. Entity type id kessai_gateway_instance -> kessai_payment_account, config prefix gateway_instance -> payment_account, the five classes, the @api interface, the entity labels, the two assertGateway() refusals and the two loadGateway() refusals, the config schema, entity_mapping.neon, the docs and both French catalogues.

Gateway is kept for what it correctly names: the plugin that says how to talk to a provider. An account is one configured use of one gateway, so PaymentGatewayManager, PaymentGatewayInterface, the kessai_payment_gateway plugin type and the kessai.gateway.<plugin> settings schema are untouched.

Swept while here: kessai_worldline/README.md still described the settings form #3621924 (closed) deleted, and the settings.php secrets it replaced with key entities.

Found auditing the branch

The Worldline account form answered 500 on a site with one language. Its locale map description linked to the language module's languages page unconditionally, and building a link to a route the site does not have raises rather than rendering nothing. A site with one language does not install that module, so on the ordinary Drupal install a Worldline account could not be added or edited at all. It predates the account form; the only test of that form installs the language module, which is exactly why nothing caught it. The link is now made only when there is a page to link to, and the words are the same either way so there is one sentence and not two. WorldlineAccountFormMonolingualTest opens the form without the module: 500 against the unfixed code, 200 with it.

The section's menu weight was -6, which is Appearance's. Two siblings of one weight are ordered by title, so the section sat before or after Appearance depending on the interface language. -9 puts it between Content and Structure and collides with nothing.

Nothing covered the section page. A menu link naming a parent that does not exist, a link left in another menu, or a mistyped controller each produce an empty section or a fatal, and no linter reads a controller string or a menu parent. PaymentsSectionTest asserts all six entries by title and by href -- two declared here, four by kessai_views -- plus the route's own title and its permission.

The key fixture both Worldline form tests need is hoisted into a trait rather than written twice.

Not in this MR

PaymentClientInterface::create(string $gateway, ...), getAvailableGateways(), isGatewayAvailable() and the payment's gateway column keep their names. Renaming those is a second wave that changes the consumer API and the stored column, and it belongs in its own issue rather than inside a UI change.

Consequences for an installed site

• Accounts are under kessai.gateway_instance.* and need moving to kessai.payment_account.*. Pre-1.0 with no release, so there is no update path to write.
• The four listing views carry their paths in exported configuration, so an installed site keeps admin/config/services/kessai/* until that configuration is updated too. The links still work; they simply do not sit under the new section's path.
• yoyaku names the removed route entity.kessai_gateway_instance.collection in a help text, and the interface in PaymentGatewayResolverTest. That is [#3622816] / yoyaku!349 (merged), which should land after this.

Gate

phpcs (Drupal,DrupalPractice, CI's extension list) 0 errors 0 warnings; phpstan level 5 [OK] No errors; cspell against CI's own config, 148 files, 0 issues, the config first verified to reject colour/handback/behaviour; per-project potx audit in both directions back to its baseline, 0 new orphans; docs/metrics.md regenerated.

Suites run against core 12 in a disposable container: 286 kernel tests / 2746 assertions and 34 functional tests / 254 assertions, all passing.