#5335 added the ComponentHostPlugin adapter, a WebAssembly component that provides a host capability from its own supervised store but nothing could actually load one outside of tests. This PR adds the production loading path across all three host front-ends, plus an end-to-end test.

A host component plugin is loaded exactly like a built-in Rust plugin (HostBuilder::with_plugin, started at Host::start); the only new work is turning a declaration (an id + a place to fetch the wasm) into a registered plugin.

Runtime primitive (wash-runtime)

• ComponentPluginSpec / PluginSource — a plain, always-compiled declaration (id + OCI-image-or-file source + optional max_restarts / digest pin), with a FromStr for the CLI grammar.
• load_component_plugin (gated on host-component-plugins) — fetches the wasm (oci::pull_component or tokio::fs::read), verifies an optional digest pin, and builds the ComponentHostPlugin. The caller registers it with with_plugin before Host::start.

wash host (cluster / operator path)

• --host-plugin / WASH_HOST_PLUGINS (repeatable). Comma-separated key=value: id=<name>,image=<ref>[,pull=…][,max-restarts=N][,digest=…] or id=<name>,file=<path>.

wash dev (local path)

• dev.host_plugins config entries (file or image source).

Chart (operator path)

• Per-host-group runtime.hostGroups[].hostPlugins values, rendered into --host-plugin args on the host Deployment.

# wash dev — .wash/config.yaml
dev:
  host_plugins:
    - id: acme-kv
      file: ./build/kv_plugin.wasm
      maxRestarts: 3

# chart — values.yaml
runtime:
  hostGroups:
    - name: default
      hostPlugins:
        - id: acme-kv
          image: ghcr.io/acme/kv-host:1.0.0
          pullPolicy: ifNotPresent

Design decisions

• Host-operator controlled only. A host component plugin runs with the host's capability surface and serves every workload that imports its interface — a privileged install. So it's declared in host config; nothing in a WorkloadStartRequest can register a host-global provider.
• Static at host start. There is no dynamic-plugin API (HostApi is only heartbeat/workload_start/status/stop) and the registry is fixed after build(). Loading resolves once at boot. Dynamic load/unload on a running host is noted as future work (needs a mutable registry, workload re-bind, and an Arc<str> id).
• All-features-only, and it fails loud. The loader is gated on host-component-plugins (not in release builds). The spec/flag/config types are always compiled, so a plugin declared against a release host produces a clear "requires the feature" error rather than a silent drop — important for the operator/env path.
• Host CRD is status-only. It's created from the host's heartbeat (HostPodReconciler only bridges pod↔Host lifecycle); host pods are Helm-templated per host-group. So the declarative host-config seam is the host-group values, which is where hostPlugins lives.
• &'static str id is interned via a bounded Box::leak (plugins load once at startup and live for the process); flagged to revisit if dynamic loading lands.

Testing

• Unit: ComponentPluginSpec grammar parsing (valid/invalid).
• Integration: load_component_plugin from a file builds a plugin with the right id/world; digest-pin-on-file and missing-file error paths; and an opt-in OCI-source test (HOST_PLUGIN_OCI_REF, self-skips in CI).
• Config: HostPluginConfig::to_spec validation + dev.host_plugins YAML round-trip.
• e2e (runtime-operator/test/e2e/host_plugin_test.go): a ginkgo/kind spec that loads a plugin onto a hostGroup via hostPlugins, deploys a workload importing the plugin's acme:kv/store, and asserts a value written via /set reads back via /get — proving the CLI/chart loading path and cross-store bind work in a real cluster.

Verified end-to-end locally in kind against a registry:2 on the kind network: built the all-features host image, pushed the two fixtures with wash oci push, and ran the ginkgo spec — the host pulled the plugin from OCI, loaded it, an acme:kv workload scheduled and reached Ready, and /set→/get round-tripped a value through the plugin's store. SUCCESS! -- 1 Passed. The gated OCI-source load_component_plugin test and a direct wash host --host-plugin … run were also verified against the same registry. In CI this stays gated on the two fixtures being published (HOST_PLUGIN_E2E_IMAGE, HOST_PLUGIN_CALLER_E2E_IMAGE).

Follow-up to activate the e2e

The e2e self-skips until two fixtures are published (same bootstrap the implements/messaging specs used), because host plugins load at host startup. A non-pullable image would fail host boot and break the all-features leg. To turn it on:

1. Publish crates/wash-runtime/tests/fixtures/kv-plugin and kv-plugin-caller as OCI images.
2. Fill the empty host_plugin_image / host_plugin_caller_image matrix values in wash.yml (all-features leg).