refactor(ui): unify the CapabilityStatement implementation shared by HFS and HTS

[smunini]

Closes #808.

Where it landed

helios-ui-chrome — the crate #543 already created. #808 asked the PR to say
which: this stacks on that extraction rather than creating a new minimal crate.

What is shared now

helios_ui_chrome::capability owns the projection and the four cards both
products stack:

• build_view and the view model (CapabilitySummary, SystemInteraction,
  OperationRow, InteractionTag, ResourceRow), plus
  safe_canonical_href, system_interaction_href,
  resource_definition_href and interaction_tag_class.
• templates/partials/capability-{summary,interactions,operations,resources}-card.html,
  rendered through a CapabilityCards builder.

The crate stays a leaf — serde_json + url, no axum, no HTTP client, no
FHIR schema pack — because the two questions it cannot answer are supplied by
the caller:

	supplied by HFS	supplied by HTS
DocsVersion (which release to link into)	total match on FhirVersion	DocsVersion::from_code(state.fhir_version)
CoreResourceCatalog (does this type have an official page in that release?)	the validator's core schema packs	the three types a terminology server serves

Keeping FhirVersion out is deliberate: its variants are #[cfg]-gated, so
naming it here would drag a leaf crate into the R4/R4B/R5/R6 feature matrix of
both products for the sake of four documentation roots.

What each page keeps, because the difference is real

• Fetching. HFS self-calls over loopback; HTS proxies two upstreams.
• Degradation. HFS still degrades the whole page to one warning — it has
  one source to fail. HTS still degrades card by card, now by handing the
  shared cards the hts-degraded-reason-* sentence as a notice, so per-card
  degradation costs no duplicated card headings.
• The raw fold. HFS's bounded, paginated JSON-fragment tree (ui: Capability Statement raw JSON is never syntax-highlighted — the statement always exceeds the 4,000-line render budget #798) and
  HTS's byte-capped inline <pre> both keep a 400 KB+ statement off the page,
  by different means. Neither is the other's markup, so neither moved.
  Unifying that is json_view's problem, and hts-ui: "Raw request and response" fold has no expand affordance, no highlighting, and drops the payload on errors #803 has since become a
  different issue.
• The Terminology capabilities card, which only HTS can have.

Behaviour changes

All on the HTS page, which is the one that had been missing the improvements:

• Resource types and operation definitions are now links into the release the
  binary was built for, and interaction verbs carry the semantic tag palette
  (tag--member / tag--config / tag--excluded / tag--muted).
• "Base URL" now shows implementation.url, which is what the label
  promises, rather than the statement's own url canonical — that identifies
  the document, not the endpoint. HTS emits no implementation.url, so the
  row renders an em-dash; the canonical is still in the raw fold.
• Absent summary fields render an em-dash rather than a blank cell, on both
  pages.
• rest[] is flattened across every server component instead of reading
  rest[0] (HFS's old reading). rest is 0..*; mode: "client" components
  are excluded, since they describe what the server calls, not what it serves.

No new Fluent keys — the cap-* catalog was already shared.

Acceptance criteria

• One parser produces the view model both pages render.
• The version-correct documentation links work on both pages.
• Interaction verbs are colour-coded identically on both.
• The HTS Terminology capabilities card still renders.
• HTS still degrades per-card when one upstream fetch fails.
• The raw-statement block handles a 400 KB+ statement without wedging the
  page, and states plainly when it truncates. (Unchanged on both sides:
  HFS never inlines it, HTS caps it and says so. The HTS test that fires a
  bulky statement at the page still passes.)
• Existing tests pass or moved. crates/ui/src/capability.rs's
  projection tests moved to crates/ui-chrome/src/capability.rs and grew
  card-rendering coverage; what stays in crates/ui is what only HFS can
  assert (the FhirVersion → DocsVersion mapping, the core-pack
  catalog's per-release answers, CreateTargets).
  crates/hts-ui/tests/capability.rs keeps its page-level tests and its
  CSS-class guard now scans the shared partials too.

Verification

cargo test -p helios-ui-chrome -p helios-ui -p helios-hts-ui
cargo build --workspace
cargo clippy -p helios-ui-chrome -p helios-ui -p helios-hts-ui --all-targets
cargo check -p helios-hts-ui --no-default-features --features R5

All green. Two flakes surfaced in crates/ui/tests/bulk_export_http.rs
(a_retry_that_loses_its_cas_retries_transient_cleanup_until_404, then
a_poll_version_bump_does_not_discard_a_concurrent_second_start) — different
test each run, both pass on rerun, and neither touches this code.

Not run: the Playwright e2e suite. The specs that pin this page's structure
(design-system.spec.ts asserts section.card > .card__body > .kv-grid >
seven .detail__field; capability-statement.spec.ts asserts the filter's
hidden version input, the resource links and the JSON fragment tree) all
target markup this PR preserves, and the shared crate has unit tests pinning
that shape — but they are worth a run before merge.

https://claude.ai/code/session_01Kos63w6bGcUoLtCxWGDaZY

[codecov]

Codecov Report

❌ Patch coverage is 96.67705% with 32 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
crates/hts-ui/src/capability.rs	75.23%	26 Missing ⚠️
crates/ui-chrome/src/capability.rs	99.57%	3 Missing ⚠️
crates/ui/src/lib.rs	95.58%	3 Missing ⚠️

📢 Thoughts on this report? Let us know!

[claude]

Code review

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