feat(ui): SearchParameter viewer (#238) + Compartment viewer & route tester (#237) — read halves

[angela-helios]

Implements the read halves of #238 (SearchParameter viewer) and #237 (Compartment viewer + route tester) in helios-ui, following the interactive mockups from #247, the standalone hi-fi console design, and Brett's Figma file (CcLtq79cH2aHv4Ii9aNQTP). Stacked on #241 (feat/234-saved-queries); retarget/rebase once that merges.

Scope: the slice both issues said to ship first

• SearchParameter viewer & editor UI: Resource Filter rail, faceted browse, CRUD with registry-aware validation #238's acceptance criteria: "Read-only viewer ships against the current registry (no Store SearchParameters in storage; make the in-memory registry a TTL cache over it #235 dependency). Write paths land behind Store SearchParameters in storage; make the in-memory registry a TTL cache over it #235." Store SearchParameters in storage; make the in-memory registry a TTL cache over it #235 is still open, so the editor's write half stays off; the page says so explicitly (sp-writes-pending).
• Compartment Editor UI: CRUD for CompartmentDefinitions + a compartment route tester #237's open question 1 (is there a tenant-scoped override layer at all?) is unanswered, and question 2 suggests shipping the tester first. This PR ships the read-only Definition/Members views plus the tester.

GET /ui/search-parameters (#238)

• Same snapshot the server searches with. The catalog seeds exactly like the storage backends: load_embedded() fallback first, then load_from_spec_file() from HFS_DATA_DIR (default ./data), first canonical URL wins — mirroring SearchParameterRegistry::register. A missing spec bundle renders a visible warning instead of silently under-reporting. Lazily loaded per FHIR version, cached for the process lifetime.
• Resource Filter rail — search box, All types, Recently used, live counts per base type. The rail is a direct view of the registry's base → code → param outer map. Recents are a progressive enhancement (resource-filter.js, localStorage); everything else is links + a GET form, so the page works with JavaScript disabled.
• Type and source facet rows scoped to the current base type, with live counts.
• Pagination (50/page) rather than a render cap, per the acceptance criteria.
• Detail panel for the selected row: canonical URL, type, bases, FHIRPath expression, targets, composite components, and the runtime status with the draft→active promotion hint (issue open question 1 — showing runtime status, with the promotion explained).
• Registry-aware chips and notes, using the fix(search): resolve (base, code) shadowing by source precedence #242 semantics: a cross-source (base, code) shadow renders as informational overrides spec / shadowed; a same-source collision is the blocking conflict (DuplicateCode). Warnings for empty expressions (extractor indexes zero rows) and reference params without targets; informational note for choice-type expressions (rewrite_choice_types()).
• Version pill re-keys the screen across whichever of R4/R4B/R5/R6 the build enables (helios-ui grew version features, forwarded from hfs via helios-ui?/…).

GET /ui/compartments (#237)

• Rail of definitions with members / total counts (Patient 66/145 etc.), Definition tab (canonical URL, status, search/experimental, publisher, description — read-only, stated as such), Members tab with member/excluded chips, per-type linking params, and the Members · All types · Excluded filter.
• Tester: pick id + target type (or *). Resolves through helios_fhir::compartment_params() — the same codegen'd table the REST compartment handler consults — so the answer here is the answer the API gives:
  • member → the equivalent flat search (subject=Patient/example OR performer=Patient/example),
  • non-member → the 404 + OperationOutcome preview,
  • * → fan-out across member types, with the skipped-not-failed note matching the handler's filter_map,
  • {def} (e.g. Encounter in its own compartment) → explained as the compartment resource itself.
• Definition metadata comes from the spec CompartmentDefinition JSONs vendored under crates/ui/data/compartments/ (the same files fhir-gen compiles; the crate can't include_str! across crate boundaries without breaking cargo package). A parity test asserts every (compartment, type) slot in the vendored copies matches the codegen table, for every enabled version — the vendored data cannot drift silently. The questionnaire.json oddity (no code, zero resources) is not vendored, per issue open question 4.

Design

Both pages implement the #247 mockups on the existing design system: app.css tokens, Figtree, the card/radius/shadow scale from the Figma Dashboard frames, and the Search screen's table styling. New semantic tokens --ok / --warn / --danger (+ soft variants) are held off the accent hue, defined for both themes. The pages reuse the crate's htmx-first conventions: server-rendered pages at real URLs, hx-boost for swaps, an hx-select live rail filter — no client-side state beyond the recents enhancement.

The sidebar's Compartments entry goes live, and a Search Parameters entry joins the Server section; strings added to en/es/de.

Tests

• Parity: vendored compartment JSONs == get_compartment_params() output, all versions.
• Tester membership/404/fan-out/{def} cases against real R4 data (Patient 66 members, subject OR performer, etc.).
• SearchParameter snapshot: full 1,375-param bundle loads, base filter narrows with facet sums matching, pagination is stable and complete, missing spec dir degrades to the fallback with the warning flag set.
• Chip semantics: cross-source mates → overrides/shadowed, same-source → conflict.
• Router: both pages end-to-end through mount(), including the tester round-trip and detail-panel selection.

Notes / follow-ups

• mount() now takes the data dir: helios_ui::mount(app, version, config.data_dir.clone()).
• Custom parameter files (load_custom_from_directory, Config source) aren't in the snapshot yet — worth folding in together with Store SearchParameters in storage; make the in-memory registry a TTL cache over it #235's storage-backed registry, which is also when the editor's create/override/delete lands.
• Compartment definitions ship version-scoped including R6's Group compartment.

Closes nothing yet — read halves only; #238 and #237 stay open to track the write paths.

[angela-helios]

90b44da7 grows the queries page's builder to the rest of the hi-fi Search screen — it lives on this branch (not #241) because the parameter catalog is fed by #238's registry snapshot:

• Visual rows ⇄ URL: Conditions (param / modifier / value), Includes, and Result controls stay in two-way sync with the featured GET URL. Colon modifiers rejoin the key, comparator prefixes (ge, le, …) rejoin the value.
• Registry-fed suggestions: GET /ui/queries/params?type=X returns a server-rendered <datalist> fragment (options labeled with the param type) from the same snapshot as /ui/search-parameters, swapped as the URL's type changes. Hypermedia, not a UI JSON API.
• In-page results: Run fetches the search from the FHIR API itself and renders Bundle.total, a table honoring _elements (compact HumanName/CodeableConcept/Reference/Quantity formatting), OperationOutcome diagnostics on errors, and paging over Bundle.link. Explicit runs record to recentSearches; paging doesn't. ?url= deep-links into a loaded builder + executed search.

Verified against a running hfs with seeded Patients (screenshots below reflect /ui/queries?url=/Patient?name=smith&_elements=name,gender,birthDate). The hi-fi's AI search panel is the remaining piece of that screen — needs an NL→FHIR-URL backend, so left as a follow-up.