Pin a step's payment through kessai's contract instead of on its table

Problem/Motivation

The payment step remembers which workflow token asked for a payment, and whether the run wants the payer's stored token forgotten when it ends. Both were base fields this submodule added to kessai_payment, with a storage-schema subclass swapped in to index one of them.

That is a column on another project's table. It works only while orchestra and kessai share a database, it is not orchestra's table to shape, and a kessai settling payments on another host could not carry it at all. Several more places reached into that table by name to find a step's payments and to delete a gone run's.

The module also declared a dependency on the payment engine, so installing it put an engine on every site - including a site whose payments are settled elsewhere, which is the one site that must not have one.

Proposed resolution

Ask kessai for what orchestra needs, and keep orchestra's own knowledge on kessai's terms.

• The pin is payment metadata. Orchestra's own names and string values, which kessai stores, indexes and never reads. OrchestraPaymentEntityHooks, PaymentStorageSchema and the hook_entity_type_alter() that swapped it are deleted, along with the two base fields and their French.
• It travels with the payment request, so creating a pinned payment is one call rather than two, and one request rather than two against a kessai on another host. Nothing writes a pin afterwards: a reusable pending payment is one the same token's own lookup found, so it already carries that token's pin.
• The token a payment is pinned to is read off the payment, with no lookup. That is the direction a provider webhook, the expiry sweep and a back-office capture need, because each arrives carrying a payment and nothing else.
• The run's payments are one indexed lookup for the whole run rather than one per token.
• The run-end token cleanup is one index read. The retention flag holds the token id rather than a yes or a no and is absent when the answer is no, so a run that flagged nothing - which is nearly every run - is answered without a payment being loaded.
• The settle step reads the run's payments most recent first. That order decides which authorization is captured and which is released, so it is stated where the payments are produced rather than assumed.
• Deleting a gone run's payments goes through the contract, which takes their claims, refunds and reversals with them.
• The dependency is the contract, kessai:kessai, and no production file names Drupal\kessai_engine. Which module settles a site's payments is the site's decision, not this one's.

Remaining tasks

None. Depends on kessai !79, which is merged.

User interface changes

None.

API changes

PinnedPayment's finders take verb+noun names and answer with payments rather than queries. The class is this submodule's own.

Data model changes

The orchestra_token and delete_token_on_end base fields are removed from the payment entity, and the payment storage schema is kessai's own again. What orchestra remembers lives in kessai's payment metadata.

AI-Generated: Yes (Claude Code was used to help produce this change.)