Resolve #3629993 "Move the booking workflow's cancellation quorum to the new quorum settings and route on its result"

Closes https://www.drupal.org/project/yoyaku/issues/3629993

orchestra #3629948 (orchestra!665 (merged)) reworks the quorum join's settings:

• quorum_condition, a flow condition tested on each arrived branch, replaces counting collect against approve_value. quorum_value replaces count, in the unit quorum_unit names (a count by default; also a percentage or a majority).
• An optional quorum_result receives, when the join fires, the number of branches the condition held on.

The booking workflow's n_cancel_join still uses the old keys. Once orchestra!665 (merged) lands, that quorum has nothing to count: it waits for every branch instead of firing on the first cancellation, and it stops writing cancel_votes, the list f_join_canceled routes on.

This MR:

• n_cancel_join: quorum_condition a comparison, cancel_outcome == canceled; quorum_value: 1 (the default unit, a count); quorum_result: cancel_count. Keys are in the schema's order.
• f_join_canceled: routes on the result with a comparison condition, cancel_count >= 1, instead of a count condition over the collected list. The join therefore no longer collects anything, and cancel_votes is gone (nothing else read it). The flow's condition in the BPMN copy is updated to match.

Checked locally against both heads in drupal11-test, again after orchestra!665 (merged) was rebased on 1.x and its quorum value renamed: BookingWorkflowE2eTest passes 5/5. With unfixed 1.x yoyaku all 5 fail at install, on the config schema. Turning the condition into != fails the "cancel confirmed tears down deposit and cancels" and "manual settlement reaches attendance" scenarios.

orchestra!665 (merged) is merged, so CI here runs against the engine that reads the new settings.

It also fixes the two phpstan findings the lane reports on yoyaku_placement, code this change does not otherwise touch (yoyaku 1.x's own last pipeline stopped at composer, so they never showed there):

• Together::seatInFewestRuns(): phpstan read count($taking) >= $best['runs'] as always true. That was its narrowing of the array shape across the two loops, not the code: the fewest runs found so far is now kept as a number of its own, starting at PHP_INT_MAX (none found yet), and $best holds the proposal itself.
• VenuePlacementProvider: the $closeness ?? SeatingCloseness::Adjacent fallback could never apply (the last branch is only reached with places seated, and every seated proposal sets the closeness), so the variable is used directly.

The placement kernel tests touching both (SeatTogetherTest, VenuePlacementProviderTest, CartPlacesApartTest, SlotBookingPlacementTest, PlaceBookingTest, OrphanedPlacesTest, PlaceOrphansTest, AreaChoiceTest, PlacesApartPolicyTest), SeatingMessagesTest and the functional PartiesAtOnceTest and VenuePlaceFilterTest pass locally; phpstan on the whole module is clean.

AI-Generated: Yes (Claude Code was used to help write this change and description. I reviewed it.)