Wire up the Resource list filter UI (drive from /metadata + per-type $summary=count)

[smunini]

Summary

Wire up the Resource list filter UI in crates/ui so the user can filter/browse by FHIR resource type. The filter should be driven by data from the server rather than a hardcoded list.

Data sourcing

1. Get the list of resource types from the FHIR capability statement at GET /metadata (note: the endpoint is /metadata, not _metadata). Read CapabilityStatement.rest[0].resource[*].type to build the candidate list of supported resource types.
2. Get a count per resource type by issuing GET /{ResourceType}?_summary=count for each type and reading Bundle.total.
3. Populate the filter UI from the resulting (resourceType, count) pairs.

Notes / open questions for the implementer

• /metadata can advertise ~150 resource types, so step 2 fans out into ~150 requests. Decide how to handle that: issue them concurrently with a bounded concurrency limit, and/or fetch counts lazily. Please note the approach chosen in the PR description.
• Decide whether resource types with a count of 0 are hidden, or shown greyed out/disabled. Showing them disabled is probably friendlier, but it makes the list long.
• Counts should be cached server-side for a short TTL so every page render doesn't re-fan-out. Cache invalidation on write is out of scope for this issue.
• Requests must be tenant-scoped — the counts have to come back through the same tenant routing the rest of the UI uses.
• Handle the failure cases: /metadata unavailable, an individual count request failing or timing out (render the type without a count rather than failing the whole page).

Suggested touch points

• crates/ui/src/lib.rs — route + handler for the filter/list partial
• crates/ui/templates/ — new partial for the filter control; follow the existing partials/status.html + htmx pattern
• crates/ui/src/i18n.rs and the Fluent locale files — any new user-visible strings must be localized, not hardcoded

Acceptance criteria

• The resource filter list is rendered from /metadata, not from a hardcoded array.
• Each entry shows the resource type and its count from ?_summary=count.
• Zero-count and error-state behavior is implemented and documented in the PR.
• Counts are tenant-scoped.
• New strings are localized.
• Tests cover: filter renders from a stubbed /metadata, and a failing count request degrades gracefully.

[smunini]

We should also wire up the FHIR Version selector. https://build.fhir.org/http.html#version-parameter

[angela-helios]

Absorbed by the Resources page (#282, shipped in #283/#290): the type rail is conformance-driven and hydrates live per-type counts. Closing as completed there.