Follow kessai's renames: deleteStoredTokens(), setStoreToken()/setTokenValidUntil() and PaymentHandoff::getUrl()

Problem/Motivation

kessai is a gateway-agnostic payment engine, so a card is a gateway's word and not the engine's: what it holds is a token, and the human at the other end is the payer. kessai #3621923 takes the card out of its vocabulary and shapes what is left by audience, and both of those rename public API that orchestra_payment calls.

Three call sites, in two files:

• src/Plugin/Interaction/PaymentInteraction.php:1198 carries the step's retention choice onto the payment it just created, through setStoreCard() and setCardValidUntil(). Those become setStoreToken() and setTokenValidUntil(), and the two base fields behind them move with them: store_card becomes store_token, and card_valid_until becomes token_valid_until.
• src/Plugin/Interaction/PaymentInteraction.php:1217 builds the payer's handoff URL with PaymentHandoffController::getHandoffUrl(). How a consumer begins a payment is no longer a static method on an HTTP controller: it is PaymentHandoff::getUrl() in kessai's own namespace, so the import changes with the call.
• src/EventSubscriber/StoredCardCleanupSubscriber.php:81 forgets the run's flagged tokens when the instance ends, through deleteStoredCard(), which becomes deleteStoredTokens().

Nothing else in orchestra is affected. Every other method it calls on the payment manager stays where it is, the entity query on delete_token_on_end and token beside the third call reads no renamed column, orchestra_payment's own PaymentStorageSchema subclass keeps working because that extension point is unchanged, and no test double carries an old signature.

Until this lands against the new kessai, a payment step stops recording whether to keep a token, the payer's handoff link cannot be built at all, and the end-of-run cleanup raises Call to undefined method inside the subscriber that exists to stop a live alias being abandoned at the provider.

Proposed resolution

Rename the four calls, change the one import, and say token rather than card in the comments and the log line beside them, so the two modules read the same way about the same thing.

The wider vocabulary question in orchestra is a separate decision and is not forced by this: Payable::$storeCard and Payable::$cardValidUntil, PayableResolverInterface and StoredCardCleanupSubscriber are orchestra's own names, and the first two are read by every payable resolver outside this project.

Remaining tasks

This has to land together with kessai #3621923, not before and not after: each method exists under one name or the other, never both. kessai renames two base fields, so the site is reinstalled when it lands. yoyaku #3622616 carries two call sites of its own on the same rename.

User interface changes

None.

API changes

None in orchestra. It follows renames in kessai.

Data model changes

None owned by orchestra. The two kessai columns behind the renamed setters move with kessai.

AI-Generated: Yes (Claude Code was used to help draft this issue summary. The call sites were enumerated across every local docroot and read before it was written.)