Task: Holiday-aware date picker widget

A reusable Qt widget that lets a user pick a date while showing which dates are holidays, given one or more calendars as input (reusing calendar's holiday-adjustment data — Calendar entity follow-ups: date picker, list-pagination fix, QuantLib materialization). Holidays for the union of the input calendars are visually highlighted in the date grid (weekends included, following the same convention QuantLib's calendar classes use). When multiple calendars are given, it must be clear which calendar(s) a given highlighted date's holiday is coming from — e.g. a tooltip on hover naming the source calendar(s) — not just an undifferentiated highlight. This widget becomes the standard way to pick any date that is calendar-sensitive across the app (e.g. trade dates, fixing dates, spot dates) — not just within currency/currency-pair screens.

Depends on Model the calendar entity for codegen existing first, since the widget needs a real calendar → holiday-dates data source, not free text.

Also depends on Materialise QuantLib calendar holidays and support calendar adjustments: this widget reads from that task's materialised calendar_dates table (base QuantLib dates plus any calendar_adjustment overrides) rather than calling into QuantLib live from the UI.

• [X] A reusable widget exists (HolidayAwareDatePicker, ores.qt.api) that accepts one or more calendar codes and highlights their non-business dates in the popup date grid.
• [X] Weekends are highlighted using the same convention as holidays – calendar_date::is_business_day covers both, undistinguished by design (see its own doc comment), so the widget highlights every non-business date uniformly rather than re-deriving a separate weekend mask client-side.
• [X] Hovering a highlighted date shows a tooltip naming which input calendar(s) it's non-business in — clear attribution when multiple calendars are given, not just an undifferentiated highlight.
• [X] Widget is documented in the Qt UI patterns doc (new "Reusable input widgets" section), alongside its siblings OreDateEdit and CalendarAssignmentWidget, so other screens know to reuse it instead of a plain date picker for calendar-sensitive dates.
• [X] At least one real usage wired up as a proof point: SwapInstrumentForm's fraFixingDateEdit (FRA Fixing Date).
• [X] The date picker highlights materialised calendar_dates rows fetched from the server, not a live QuantLib computation — sourced from Materialise QuantLib calendar holidays and support calendar adjustments via fetch_calendar_holidays().

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

Requested again during manual QA of the calendar Qt screens task (2026-07-19): tester asked for "some kind of hand crafted notebook page to show the holidays for the calendar" when reviewing a CalendarDetailDialog row. This task's scope (holiday-aware picker, reusable everywhere a calendar-sensitive date is entered) covers that need; no longer blocked, since Model the calendar entity for codegen has landed.

All six acceptance criteria met. Shipped HolidayAwareDatePicker (ores.qt.api), a drop-in OreDateEdit replacement that highlights non-business dates in its popup calendar for one or more calendars, sourced from the server's materialised calendar_dates table via a new fetch_calendar_holidays() helper (paged, windowed, never a live QuantLib call). Tooltips on hover name which calendar(s) a highlighted date applies to. Documented in the Qt UI patterns doc alongside its siblings; wired into SwapInstrumentForm's FRA Fixing Date field as the proof point.

Two deliberate, documented scope limits (see Plan):

• The widget loads a practical window (1y back / 5y forward) around the popup's shown month, not the full multi-decade materialisation horizon, expanding lazily as the user navigates further.
• The proof-point wiring uses a static TARGET calendar default rather than deriving it from the form's selected currency – no client-facing currency-to-calendar lookup exists yet (currency_calendar has no NATS service/protocol layer, matching CalendarAssignmentWidget's own precedent); wiring that up is new, separate scope.

Verified: full local build clean (linux-clang-debug-make, including ores.qt.exe linking); ctest 72/74 passed, excluding the two pre-existing, already-captured ores.iam failures unrelated to this change. Manual verification was partial: the Qt client launches cleanly with the new widget's code loaded (confirmed via compass client start), but this session had no display/screenshot tool to click through and visually confirm the popup's highlighting/ tooltip – flagged honestly rather than claimed. A human (or a future screenshot-capable session) should do that pass.