docs(crds): reflect Bailey's feedback — canary-only for implements

Per @ricochet on the PR: `wasm_component_model_implements` is intended
to be enabled in canary builds only, not in release tags. My earlier
commit overreached and claimed the release image ships with the
feature by default.

Rework the callout to state what's actually committed to:

- Release images `ghcr.io/wasmcloud/wash:X.Y.Z` do not commit to the
  feature — same wording direction as pre-2.5.2, with the incidental
  (and inaccurate) `ghcr.io/wasmcloud/runtime-operator` mention still
  removed.
- The `ghcr.io/wasmcloud/wash:canary` tag IS built with the flag for
  wasmCloud's own multi-backend CI (verified: the canary and 2.5.2
  manifest digests currently match, and `.github/workflows/wash.yml`
  sets `CARGO_FEATURES=wasm_component_model_implements` on the pushed
  image build). Users can point `runtime.image.tag` at it for
  evaluation, with the caveat that the canary manifest moves on every
  main merge.
- For a pinned surface, build a custom host image with the same Cargo
  feature — unchanged from the previous doc guidance.

Line 169 reverts to "Enabled in 2.5.0" (drop my "default in 2.5.2"
sentence). The default-backend paragraph (unlabeled wasmcloud:blobstore
and wasmcloud:keyvalue/store) stays — that's #5309 and is real in
release.

Signed-off-by: Eric Gregory <eric@cosmonic.com>

Author: ericgregory

docs/kubernetes-operator/crds.mdx

@@ -166,7 +166,7 @@ Use the `hostInterfaces` field to define host interfaces used by the workload. E
 
 The optional `name` field enables **multi-backend binding**, meaning a component can import the same interface twice under distinct labels and have each labeled import routed to its own backend. This uses the Component Model's `implements` clause: the component declares each labeled import in its WIT world, and the runtime routes calls through the labeled namespace to the matching `hostInterfaces` entry.
 
-Introduced in 2.5.0, the Component Model's `implements` proposal (Cargo feature `wasm_component_model_implements`) is what allows the runtime to bind the labeled imports at start time. As of 2.5.2 the feature is enabled by default in the published `ghcr.io/wasmcloud/wash:{{WASMCLOUD_VERSION}}` image and in the wash CLI binaries — no custom build required.
+Enabled in 2.5.0, the Component Model's `implements` proposal (Cargo feature `wasm_component_model_implements`) is what allows the runtime to bind the labeled imports at start time.
 
 A component that needs two `wasi:keyvalue` backends declares two labeled imports in its WIT world:
 
@@ -180,8 +180,8 @@ world my-app {
 
 Inside the guest, each label surfaces as its own import namespace: `cache::open("kv-bucket")` and `sessions::open("session-bucket")` reach two different backends without the guest needing to know which is which. The string passed to `open()` is the bucket name; the routing label is the WIT namespace, not an argument.
 
-:::info[Feature-flag status]
-Multi-backend binding via `(implements ..)` depends on the Component Model's `implements` proposal, exposed on the `wash-runtime` crate as the `wasm_component_model_implements` Cargo feature (which in turn depends on a Wasmtime build with `resource-implements`). As of 2.5.2 the feature is compiled into `ghcr.io/wasmcloud/wash:{{WASMCLOUD_VERSION}}` and the wash CLI binaries — the default install path just works. Embedders building their own host image can enable it explicitly by passing `CARGO_FEATURES=wasm_component_model_implements` as a Docker build arg (or `--features wasm_component_model_implements` on `cargo build`). The `implements` clause is still a Component Model spec addition being finalized upstream; once Wasmtime ships it in a tagged release, this Cargo feature moves onto the default surface and the flag goes away entirely.
+:::info[Feature flag required]
+Multi-backend binding via `(implements ..)` requires a `wash-runtime` build with the `wasm_component_model_implements` Cargo feature enabled, which in turn requires a Wasmtime build with `resource-implements`. Release images `ghcr.io/wasmcloud/wash:{{WASMCLOUD_VERSION}}` do not commit to shipping this feature. The canary tag `ghcr.io/wasmcloud/wash:canary` is built with the flag on for wasmCloud's own multi-backend CI, and can be pointed at via the chart's [`runtime.image.tag`](./operator-manual/helm-values.mdx#runtimeimagetag) for evaluation, though the canary manifest moves with every merge to `main`. For a pinned surface, build a custom host image with `CARGO_FEATURES=wasm_component_model_implements` (the source Dockerfile accepts this as a build arg) and pin the chart at that tag. The `implements` clause is a Component Model spec addition currently being finalized upstream in the WebAssembly Component Model repository. Once Wasmtime ships it in a tagged release, this feature will move onto the default surface.
 
 As of 2.5.2, multiplexed backends ship for `wasi:keyvalue`, `wasi:blobstore`, `wasmcloud:keyvalue`, `wasmcloud:blobstore`, `wasmcloud:postgres`, and `wasmcloud:messaging/consumer`. In 2.5.2, unlabeled imports of `wasmcloud:blobstore` and `wasmcloud:keyvalue/store` also work: they bind to the workload's default (unnamed) backend, so a component that needs only one backend can drop the `(implements ..)` label and still get a working binding.
 :::