Resolve the booking workflow from a profile, start it explicitly

The booking workflow was a per-resource setting (workflow, workflow_start, auto_confirm), which makes a multi-resource order ambiguous: an order can group bookings from several resources but runs one workflow, and the starter silently used the first line's resource. This moves the workflow to an order-level profile and starts it explicitly.

A new yoyaku_workflow_profile config entity holds the workflow and its auto-confirm policy, with a CRUD UI. The site default, a tenant, and a resource type each reference a profile by id; WorkflowProfileResolver resolves it type override, then tenant default, then site default.

The workflow no longer auto-starts on an order state. The payment states (locked, placed) are downstream of the workflow, so starting on them is circular, and a free order never locks. Instead WorkflowStarter::start($order) is called explicitly by a registration/checkout surface (the calendar Book button, later the cart Checkout) or an operator, and is idempotent. workflow_start and the WorkflowStartRequired constraint are removed.

One profile per order is enforced by a SingleWorkflowProfilePerOrder constraint on the transaction. The resource's workflow base fields are removed. Kernel-tested: the resolution chain and the full workflow lifecycle on the new model.

Groundwork for the multi-event booking cart. Follow-ups: tenant and resource-type profile pickers (their config entities have no admin forms yet), rejecting a cross-profile hold at add-to-basket, and moving the starter out of the EventSubscriber namespace.