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

Fixes a regression from #3613210 (the booking workflow now survives basket edits): the confirmation policy (auto-confirm vs operator validation) was resolved once at workflow start, from the first of the order line bookings including released ones. So an order re-based onto a different resource type kept the original basket policy, and a released line whose resource has no type 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.

• WorkflowProfileResolver ignores released lines: only a line in a consuming state determines the order type.
• New AutoConfirmVariableProvider resolves the policy live from the order at the prepare step; the booking workflow runs that prepare step before the placement decision (n_prepare_variables now precedes n_place); yoyaku_auto_confirm is no longer baked at start.

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

Ref #3613236.