chore(docs): update docs for 2.5.1

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

Author: ericgregory

docs/kubernetes-operator/crds.mdx

@@ -182,6 +182,8 @@ Inside the guest, each label surfaces as its own import namespace: `cache::open(
 
 :::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`. The default `ghcr.io/wasmcloud/wash:{{WASMCLOUD_VERSION}}` and `ghcr.io/wasmcloud/runtime-operator:{{WASMCLOUD_VERSION}}` images ship without this feature. To use multi-backend binding today, build a custom host image with `CARGO_FEATURES=wasm_component_model_implements` (the source Dockerfile accepts this as a build arg) and point the chart at it via [`runtime.image.tag`](./operator-manual/helm-values.mdx#runtimeimagetag). 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.1, multiplexed backends ship for `wasi:keyvalue`, `wasi:blobstore`, `wasmcloud:keyvalue`, `wasmcloud:blobstore`, `wasmcloud:postgres`, and `wasmcloud:messaging/consumer`.
 :::
 
 ```yaml

docs/kubernetes-operator/operator-manual/helm-values.mdx

@@ -350,7 +350,7 @@ runtime:
         - gc
 ```
 
-Recognized values are `component-model-async`, `gc`, `exception-handling`, `wide-arithmetic`, `threads`, and `tail-call`. The chart's `appVersion` bumps to `0.6.0` in step with this field. WASI 0.3 always brings the `component-model-async` proposal along with it, so hosts running the 2.5.0 runtime always have the async proposal available whether or not it's listed explicitly.
+Recognized values are `component-model-async`, `gc`, `exception-handling`, `wide-arithmetic`, `threads`, and `tail-call`. WASI 0.3 always brings the `component-model-async` proposal along with it, so hosts running the 2.5.0-and-later runtime always have the async proposal available whether or not it's listed explicitly.
 
 ### `runtime.hostGroups[].http.port`
 

docs/kubernetes-operator/operator-manual/roles-and-rolebindings.mdx

@@ -64,6 +64,25 @@ rules:
     verbs: ["create", "get", "list", "patch", "update", "watch"]
 ```
 
+:::info[OpenShift and `RestrictedEndpointAdmission` — 2.5.1]
+Starting in 2.5.1, the operator's ClusterRole also grants `create` on the `endpointslices/restricted` and `endpoints/restricted` virtual resources ([#5302](https://github.com/wasmCloud/wasmCloud/pull/5302)). These are required on OpenShift and any Kubernetes cluster where the `RestrictedEndpointAdmission` webhook is enabled — without them, the operator can't register a workload's host-pod IP addresses on the managed EndpointSlice, and reconciliation fails with:
+
+```text
+endpointslices.discovery.k8s.io "workload-xyz" is forbidden: endpoint address <ip address> is not allowed
+```
+
+The chart applies this permission automatically. If you're wiring RBAC manually (see [Restricting access of the Operator to Namespaces](#restricting-access-of-the-operator-to-namespaces) below), add the same rule to the operator's ClusterRole:
+
+```yaml
+  - apiGroups: ["discovery.k8s.io"]
+    resources: ["endpointslices/restricted"]
+    verbs: ["create"]
+  - apiGroups: [""]
+    resources: ["endpoints/restricted"]
+    verbs: ["create"]
+```
+:::
+
 ### 2. ClusterRole: `wasmcloud-runtime-operator-metrics-auth` — Cluster-wide
 
 Allows the operator to perform authentication/authorization checks (used to protect the metrics endpoint).

src/wasmcloud-version.ts

@@ -1 +1 @@
-export const WASMCLOUD_VERSION = '2.5.0';
+export const WASMCLOUD_VERSION = '2.5.1';