Story: Calendar entity follow-ups: date picker, list-pagination fix, QuantLib materialization

Pick up three follow-ups beyond Model calendars as proper ORE Studio reference data (Sprint 23, in progress) that aren't required by its own acceptance: a holiday-aware date picker widget, a list-truncation/pagination bug fix, and QuantLib calendar-holiday materialization.

• A holiday-aware date picker widget exists.
• The silent 100-row list truncation on entities missing has_pagination is fixed.
• Real QuantLib calendar holidays are materialised, with calendar-adjustment support.

• Promoted from the product backlog into Sprint 24 rather than starting straight into the three pre-scaffolded implementation tasks: added an analysis task first to scope each item, surface design decisions and risks, and produce an implementation plan before committing to any of the three.
• Closed the analysis task (Analyse implementation approach for calendar entity follow-ups) without producing fresh analysis: by the time it was picked up, each of the three follow-ups had already accumulated its own implementation plan organically through iterative work on the story's other tasks (the QuantLib materialisation chain alone ran to 6+ sub-tasks, all DONE). Re-deriving that analysis fresh would have duplicated, not added to, what already existed. Status per follow-up: materialisation + browse-holidays UI DONE (calendar_adjustment's own CRUD/UI still open under Materialise QuantLib calendar holidays and support calendar adjustments); pagination fix (Fix silent 100-row list truncation on entities missing has_pagination) fully scoped and ready to pick up directly (61 entities, one knob, regenerate – no design decisions left); date picker (Holiday-aware date picker widget) scoped but genuinely blocked on materialisation reaching DONE.
• extra_list_requests turned out to be domain_entity-only (every facet using it declares #+model_types: domain_entity schema, and the mustache sections are wrapped in \{\{#domain_entity\}\}...\{\{/domain_entity\}\}), so calendar_date's messaging layer instead got a parallel, deliberately minimal \{\{#junction\}\} section added to the service/protocol/ nats-handler/nats-registrar templates – covering only the paginated read-only list a browse view needs, not full CRUD. Verified via --diff against another junction (no list_by set) that this adds zero regression risk to existing entities.
• Fixed a latent codegen bug surfaced by this task: primary-key/ junction-key validation in the service templates only branched on is_uuid vs. a string-only .empty() fallback, with no case for the is_date flag that already existed in the data model. Any future entity with a non-string, non-UUID key column (e.g. a date) would hit the same compile error calendar_date did. Fixed at the template, not the generated file, and regenerated for real.
• Added a new, distinctly-named :has_parent_scoped_list:=/ =:parent_key_field:=/:parent_key_param:= knob for scoping a :has_readonly_paginated_list: list window's get-request to a parent key, rather than reusing the pre-existing parent_entity_ singular=/=has_parent_relationship mechanism – that one solves a different problem (pre-filling a foreign key on create for a still-full-CRUD entity), and conflating the two would have been confusing. Mirrored its openAddWithParent pattern instead: a new public openForParent(...) entry point delegates to a private overload, while the required zero-arg EntityController:: showListWindow() override still satisfies the base class contract. Verified via --diff against book=/=currency (knob unset) plus a temporary, reverted smoke test on currency.org with the knob set, confirming valid generated C++ with zero regression to existing entities.
• The pagination-truncation fix's original 61-entity list needed a 3-way scope split before any regeneration: 29 had a clean, real codegen model with a ** Qt drawer and current-convention primary key and were fixed directly; 16 hit a pre-existing, unrelated bug where the model still declares its primary key with a legacy * Primary key heading org_loader.py never parses (a repo-wide grep found 70+ files with this, not just these 16), split into its own follow-up; 11 have no codegen model at all (hand-written Qt predating the entity_org migration) and, having no PaginationWidget at all, present no misleading affordance – split into a lower-priority follow-up; 5 of those 45 have a model but no ** Qt drawer in it, so flipping the knob would be a no-op – split into a Qt-drawer-backfill follow-up. Rebasing onto main mid-investigation picked up a separately-merged PR that had already absorbed unrelated template-modernisation drift that was contaminating the first round of --diff output – confirms the value of syncing before large mechanical regen work rather than hand-reconciling drift that's already fixed elsewhere.
• Started migrating badge_definition=/=badge_severity's legacy primary-key heading as part of this task, then reverted: their committed generated Qt files carry hand-patched logic (an __unmapped__ reserved-code delete guard, placeholder-text tweaks) the model has no way to express, so a real regen would have silently deleted a safety check. Treated the legacy-heading migration as its own reviewed task instead of folding it into whichever entity happens to touch it next – each of the 70+ files needs individual verification, not a blind batch fix.
• Dropped QuantLib from the runtime path entirely during the materialisation task (see that task's own * Revision section): its global/static singleton state isn't safe under concurrent server request handlers, and its calendar source decomposes cleanly into a small set of timeless rules (fixed dates, nth-weekday-of-month, Easter offsets, weekend-observance shifts) plus flat one-off exceptions – a shape several independent open-source calendar libraries converge on independently. Replaced with a pure, dependency-light rule engine in ores.analytics.quant and two new refdata entities (calendar_rule, calendar_exception) with full Qt CRUD, superseding the original plan to wire up calendar_adjustment as the persisted entity – it stayed a transient export-time DTO instead, assembled only when building ORE's CalendarAdjustments file.
• Closed the materialisation task without a DQ-publish artefact for calendar_dates, confirmed with the user: the DQ-publish pattern is DQ→refdata (external data synced in), the reverse of what a table refdata computes and owns itself needs.
• Found and captured a pre-existing, unrelated defect while closing the materialisation task: ores.iam.api.tests=/ =ores.iam.core.tests fail (an assertion, FK violations, and a SIGABRT/memory-corruption crash) on unmodified main, reproduced on a branch touching zero ores.iam files. Not fixed under this story – filed as a product-backlog capture instead.
• Shipped the holiday-aware date picker (HolidayAwareDatePicker, ores.qt.api) as a drop-in OreDateEdit replacement rather than a standalone new-widget-from-scratch: highlights non-business dates via QCalendarWidget::setDateTextFormat() (no custom paint code needed), sourced from paged reads of the existing materialised calendar_dates endpoint rather than a new bulk API, windowed lazily (1y back/5y forward around the popup's shown month, expanding on navigation) rather than eagerly fetching the full multi-decade materialisation horizon per calendar. The proof-point wiring (SwapInstrumentForm's FRA Fixing Date) uses a static TARGET default rather than deriving the calendar from the form's selected currency, since no client-facing currency-to-calendar lookup exists yet (currency_calendar has no NATS service/protocol layer – deriving that mapping is separate, future scope). All three of the story's original acceptance items (date picker, pagination fix, QuantLib materialisation) are now DONE; the three pagination-scope follow-up tasks remain BACKLOG for future pickup.
• Found and fixed a real, currently-broken bug that had shipped undetected: calendar_rule=/=calendar_exception's soft-FK check against calendars.code actually checked a nonexistent id column, because their .org models set :referenced_column:, a property name the codegen template never reads (only :target_column: is consumed) – a dead-key trap in org_loader.py itself, now removed so no other entity can fall into it. Reported independently by another environment (prime_origin) via a from-clean compass db recreate; this session's own earlier "verified, tests passing" claims for the same trigger had been against a stale local Postgres schema that never picked up the (also-broken) earlier attempt at this fix – every subsequent verification in this story used an explicit db recreate first, not just a green ctest, to avoid repeating that mistake.