Confirmation policy is resolved at start from released lines, so a re-based basket skips operator validation

The booking workflow resolved its confirmation policy (auto-confirm vs operator validation) once at start, from the first of the order line bookings, including released ones. Two problems compound: since the workflow now survives basket edits (#3613210: Editing a pending basket cancels its booking workflow, and an empty order is treated as free), an order re-based onto a different resource type keeps the policy from the original basket; and a released line whose resource has no type, held first, falls through to the site-default auto-confirm profile. A free refuge booking (an operator-validation type) reached after such an edit auto-confirmed, skipping operator validation.

Fix:

• WorkflowProfileResolver ignores released lines: only a line in a consuming state determines the order type.
• A new AutoConfirmVariableProvider resolves the policy live from the order at the prepare step, and the booking workflow runs that prepare step before the placement decision, so yoyaku_auto_confirm reflects the order as it stands rather than as it was at start. It is no longer baked at start.

Covered by a new kernel test (WorkflowProfileResolutionTest) and the existing workflow E2E, both green.