feat(ui): wire the sidebar FHIR version selector

[angela-helios]

The sidebar's footer selector was a static chip hardcoding R4. This wires it per the v1 semantics agreed in #343:

• A <details> disclosure (same pattern as the tenant selector shell — works without JavaScript, opens upward from the footer) listing the FHIR versions compiled into the build, from the existing enabled_versions().
• The label is the server's default version (HFS_DEFAULT_FHIR_VERSION), no longer a literal, and that option is marked aria-current.
• Each option is a plain link reloading the current page with ?version= — the pages with a version dimension (SearchParameters viewer, Compartments) switch; pages without one ignore it. No persisted "current version" yet; that upgrade path (/_user/settings, like the theme) stays open in ui: wire the sidebar FHIR version selector (static "R4" today) #343.
• Status (already rendered by every page) carries the default version, so no template struct grew a field.

Single-version builds render a one-option menu — harmless, and it goes away on multi-version builds.

Router test asserts the options, the aria-current mark, and the server-derived label. Browser-level coverage (open the menu, switch on the sp viewer) belongs to the e2e suite and lands on #290's chain once this merges.

Closes #343.

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

[smunini]

Is this selection stored in user settings so they don't have to change it every time they log in if they are using something other than the default FHIR version?

[angela-helios]

Done — 8e69103db adds the persistence.

Selecting a version now POSTs to /ui/version, which merge-patches { "fhirVersion": … } into the same /_user/settings document the theme roams in, and bounces back to the page you were on. A per-request middleware resolves the effective version once (stored choice when it's compiled into the build, server default otherwise): the sidebar label reflects it everywhere, and the versioned pages (SearchParameters, Compartments) render under it — an explicit ?version= still wins per page.

Details worth knowing:

• The user key mirrors the REST UserKey derivation (issuer|subject, or the local fallback) — with /ui outside the auth layer today, the authenticated modes remain test(ui): exercise the conformance self-fetch and the UI under every auth mode #320's territory, same as the theme.
• Backends without a settings store (bucket-per-tenant S3 with no system bucket) degrade to a one-shot ?version= redirect instead of failing.
• Covered by a round-trip test against a real SQLite settings store: POST → 303 back to the referrer → document contains the choice; unknown versions 400.

I also updated the PR body's claim — the "no persisted version yet" caveat no longer applies.