Add install-terminologies subcommand

[alexanderkiel]

Idea

Loading FHIR terminologies (CodeSystem and ValueSet resources) into a Blaze server is currently a manual, multi-step affair: locate the right FHIR Package, download it, extract it, hand-craft transaction bundles, then blazectl upload. For users who just want their server populated with a known terminology distribution, this is too much friction.

A new install-terminologies subcommand would make this a one-shot operation:

blazectl install-terminologies \
  --server <url> \
  --registry <https-url> \
  --package <name> \
  --package-version <version>

The command resolves the package and its dependencies from a user-supplied FHIR Package registry, extracts the CodeSystem and ValueSet resources, and uploads them as FHIR transaction bundles. Re-running the command must be safe: existing resources are not duplicated (achieved via conditional create on url+version).

Why it matters

• Lower barrier to entry. New Blaze users can populate a server with a published terminology in a single command.
• Reproducibility. A --package/--package-version pair is enough for two operators to end up with the same resources installed.
• No organisation-specific defaults. The package and registry are always user-supplied; blazectl stays neutral and works against any FHIR Packages registry (e.g. packages.fhir.org, MII GitLab, internal mirrors).

Trust model

The FHIR Packages spec defines no integrity, signature, or lockfile mechanisms of its own. The NPM-compatible registry surface exposes per-version hashes (dist.shasum, sometimes dist.integrity), but those hashes come from the registry itself — a compromised registry could lie about them. The command should be honest about this:

• HTTPS is required for the registry URL.
• Every downloaded tarball is verified against the registry-published hash; the run aborts if no hash is published.
• An optional --package-integrity flag lets operators pin the root tarball's hash out-of-band, defending against a compromised registry for the root package.
• At the end of every run, a supply chain security report lists each downloaded package as either pinned (verified against an out-of-band hash) or registry-trusted (verified only against a registry-supplied hash). This is the operator's audit artefact and makes the trust assumption visible rather than hidden.

Scope

In scope: CodeSystem and ValueSet resources from a FHIR Package and its transitive dependencies. Out of scope (for now): authenticated registries, StructureDefinition and other resource types, lockfiles.