Match order constraints by pluggable order attributes (OrderContext + OrderAttributeMatcher)

The order constraint policies count by a hardcoded customer email: the plugins call getCustomerEmail() and query transaction.entity.customer_email. The dimension a policy counts by should not be baked in. It should be pluggable and composite, and it is not even necessarily the customer: a policy could count per email, per stored card, per birth date, or per an entirely non-customer value like a date or a workflow variable.

Proposed resolution

Introduce an OrderContext and pluggable matchers, and rewire the constraints to count by a configurable set of them.

• OrderContext: the assembled picture of an order (the order plus, through tagged builder services, its payment and later its workflow instance and variables). Each source module contributes what it owns, so the core stays decoupled. The caller passes only the order and the builders resolve the rest, so the context is uniform at every call site.
• OrderAttributeMatcher: a plugin type with value(OrderContext) and match(query, OrderContext). An order-field matcher adds a plain field condition (queryable); the card token matcher (in yoyaku_payment) resolves the payments sharing the same token and matches their orders. Each matcher lives in the module that owns its source.
• A policy configures the set of matchers it counts by (default email). Two orders count together only when every configured matcher matches (composite AND). "Same email or same card" is expressed as two separate policies.
• The two shipped constraints stop calling getCustomerEmail() and instead apply the policy's matchers to their count query, scoped to the pool and tenant as before.

This delivers, for example, "one refuge among all refuges by card token", so a customer cannot rebook under a different email with the same card.

Scope

This issue ships the OrderContext with its core and payment builders, the matcher plugin type, the email and card token matchers, the per-policy matcher selection, and kernel coverage. The workflow-variable matcher, the generalized capture mapping, and reusing the OrderContext for a complete-order display are follow-ups.