Let the token name the payment its step is waiting on, and let the step name the kind

Kessai stopped naming payment kinds in #3614434: Let the caller name a payment's purpose instead of choosing from kessai's two kinds: the two kind constants are gone and the kind is now a required argument, because the word belongs to whoever creates the payment. orchestra_payment does not compile against that any more, and the mechanical fix would paper over the reason it used the constant at all.

The orchestra_token field this bridge adds to a payment carries two meanings. The run-end cleanups read it as "this payment belongs to that run", which is exactly why a consumer pins its own payments there too. The settlement bridge reads it as "this is the payment the parked step is waiting on". Because one value answers both questions, the bridge needs a second test to tell a step own payment from any other payment in the run, and that test is a comparison against the kind, a word kessai no longer owns.

What to change:

• The token gains a payment field, set by the payment step: the payment that token is waiting on. Only a settlement of that payment resumes the step.
• The payment orchestra_token field goes back to meaning only that the payment belongs to this run, which is what the run-end cleanups need.
• PaymentWorkflowBridge and PinnedPayment stop comparing a kind at all.
• The payment step gains a payment_kind setting, default step_payment, so a workflow whose domain has a better word for it says so, and kessai stores that without reading it.
• TokenStorageSchema gains an indexes seam, mirroring the one kessai already offers, so the bridge can index the new field. It indexes it, because the bridge now asks which token awaits a payment on every payment event the site raises.

Both projects are pre-1.0 and reinstall-only, so nothing migrates: a run parked on a payment step at upgrade time has to be re-run.