Feat/FrontDesk Walk-in UX improvements

[Gugabit]

Changes

• Multi-guest rooms: Added accompanying-guest pickers to both the primary room and each extra room in a walk-in party, backed by (+ for extra rooms) so more than one named occupant can share a room.

• Occupancy override: Room type is still enforced by default, but a checkbox now lets staff explicitly exceed it per room (e.g. extra bed/crib for a family) instead of hard-blocking. New flag added to, honored in.

• No duplicate guests: Guests already selected anywhere in the walk-in party (primary, accompanying, or any extra room) are excluded from every other guest search, preventing the same person from being picked twice.

• Missing-field highlighting: Failed submits now visually flag the specific missing primary guest and/or room selects (for the primary room and any extra room) with an orange border/ring, instead of only showing a generic top-level error banner.

• Dynamic accompanying-guest UI: Replaced the old add/remove-button slot model with a simpler always-show-an-empty-picker pattern (FindGuest's own clear button removes a slot).

• Visual hierarchy: "Add another room" is now the prominent, full-width, dashed-border primary action; "add accompanying guest" is a smaller, indented, secondary action nested within each room's card.

• Updated locale strings

[telivity-otaip]

Good direction on multi-room + accompanying — the stage-on-primary then split flow is correct (same idea as working one PNR then splitting with flights).

Blocker before merge: while parking extra-room guests on the primary before split, we send overrideMaxOccupancy: extra.overrideOccupancy (usually false). Primary maxOccupancy still applies to that temporary attach, so a legal final layout can 400 mid-create.

Repro:

Room 1: 1 guest, room type max 2
Room 2: 2 guests, room type max 2, no override
→ attaching room 2’s second guest onto primary hits max 2 → fail, even though each final room is fine.
Fix: for attach-before-split only, force overrideMaxOccupancy: true (those guests aren’t staying on primary). Optionally add a party-service test that override skips the cap, and that false still enforces.

Also nice-to-have: test coverage for overrideMaxOccupancy; split still doesn’t enforce destination max on the API (UI-only today).