SearchResultsToolbar

import SearchResultsToolbar from "@dertour/ui/components/common/SearchResults/SearchResultsToolbar"

Internal to the Search Results body (`SearchResults_Body_Section_001`): the criteria pills (each removable) on the left, and the "Search filters" control (with an active-filter count) + the sort readout on the right. RESPONSIVE — from the real Figma frames, not invented: - Desktop `search/hotels` (7133:149711) → `filter-bar`: a 1037px-wide pill area on the left, and a 203px right-hand column holding `button/large` (203×48) with `sort-by` (162×24) beneath it. - Mobile `search-results/hotels` (7133:152476) → `filters`: a FULL-WIDTH `button/large` (343×48) with `sort-by` right-aligned 24px beneath it, and **no pill area at all** — the criteria strip is not on the mobile frame. Hence `Chips { display: none }` below `md` rather than a wrapped row. `md` (991px) is the switch because that is the breakpoint the search bar already uses for its own mobile/desktop split (`SearchBar.tsx`); Figma supplies only a 375 and a 1440 frame, so there is no designed tablet state to follow. THE SORT CONTROL, AND WHY IT LOOKS LIKE THIS There is no Figma design for it (KWRP-343) and the option list is provisional, so it is built from the AUTHORED `sort` field and rendered as a native `<select>` overlaying the existing readout: the caption, weight and chevron are the ones already designed for the readout, and the only thing added is the platform's own menu. That is the most that can be built without inventing spacing, menu chrome or motion nobody has approved — and with fewer than `MIN_SORT_OPTIONS_FOR_CONTROL` authored options it degrades to exactly the static readout that shipped. See `SearchResults.decisions.ts`. Render-only: the applied sort and the change handler are the caller's.