HiClaw v1.0.8 local install: Higress gateway stays in Envoy warming because basic-auth/key-auth WasmPlugin OCI URLs in us-west-1 require auth

## Bug Description

On a fresh local HiClaw v1.0.8 install in WSL2 (Ubuntu 24.04 + Docker Desktop), the Higress gateway inside `hiclaw-manager` never became healthy.

Element Web, Matrix, and the manager container all came up, but the AI gateway listener on `:8080` stayed stuck in Envoy **warming** state, which blocked normal manager chat behavior.

Root cause appears to be that two WasmPlugin CRDs point to OCI URLs in the `us-west-1` Alibaba registry that do not allow anonymous fetches in this environment:

- `basic-auth-1.0.0`
- `key-auth.internal`

Because the controller cannot fetch those WASM OCI images, it cannot push the ECDS configs, so the listener never fully activates.

When I changed only those two plugin URLs from:

- `oci://higress-registry.us-west-1.cr.aliyuncs.com/plugins/basic-auth:2.0.0`
- `oci://higress-registry.us-west-1.cr.aliyuncs.com/plugins/key-auth:2.0.0`

to:

- `oci://higress-registry.cn-hangzhou.cr.aliyuncs.com/plugins/basic-auth:2.0.0`
- `oci://higress-registry.cn-hangzhou.cr.aliyuncs.com/plugins/key-auth:2.0.0`

the gateway immediately recovered:
- all ECDS filters reported `update_success`
- Envoy listener `0.0.0.0:8080` became active
- health checks returned HTTP 200
- AI gateway requests started working
- manager Matrix chat started responding

This looks like a registry/bootstrap issue in Higress plugin delivery, not a frontend issue.

## Environment

- Host OS: Windows 11
- Runtime: WSL2 Ubuntu 24.04.3 LTS
- Docker: Docker Desktop with WSL integration
- HiClaw version: v1.0.8
- Install mode: local/manual
- Model provider behind gateway: Ollama via local API
- Main container: `hiclaw-manager`

## Steps to Reproduce

1. Fresh install HiClaw v1.0.8 locally in WSL2.
2. Let `hiclaw-manager` start normally.
3. Check gateway state and manager behavior.
4. Observe that:
- manager container is up
- Matrix and Element are reachable
- but gateway `:8080` is not healthy / appears stuck in warming
- manager chat is non-functional or inconsistent

## Actual Result

- Gateway listener on `:8080` does not become fully active.
- Requests to the mapped host port connect but reset or fail until plugin URLs are changed.
- Manager logs show gateway startup timeout.
- Higress gateway/controller logs show repeated wasm/ECDS errors.

## Expected Result

Gateway listener `:8080` should become healthy on a fresh local install without requiring manual edits to WasmPlugin CRDs.

## Relevant Evidence

Observed symptoms/logs included:

- `Higress Gateway did not become available within 180s` :contentReference[oaicite:0]{index=0}
- repeated `wasmconvert the wasm config` errors in `higress-gateway.log` :contentReference[oaicite:1]{index=1}
- repeated ECDS/ACK failures while the listener remained unavailable :contentReference[oaicite:2]{index=2}
- anonymous access to the `us-west-1` registry failed, while `cn-hangzhou` worked in this environment

Claude-assisted diagnosis also isolated that only `basic-auth` and `key-auth` were failing fetch/load, while `ai-proxy` and `ai-statistics` were succeeding.

## Workaround

Back up the current WasmPlugin CRDs, then change only these two CRD `spec.url` values:

- `basic-auth-1.0.0` → `oci://higress-registry.cn-hangzhou.cr.aliyuncs.com/plugins/basic-auth:2.0.0`
- `key-auth.internal` → `oci://higress-registry.cn-hangzhou.cr.aliyuncs.com/plugins/key-auth:2.0.0`

After this change:

- all 4 ECDS filters showed `update_success`
- Envoy `0.0.0.0:8080` became active
- health check returned HTTP 200
- AI gateway requests succeeded
- manager responded in Matrix again

## Suggested Fix

One of these would likely solve it:

1. ship these WasmPlugin URLs using a registry that works anonymously for local/public installs
2. mirror/fallback automatically if the default registry fails
3. avoid blocking listener activation on these plugin fetch failures for the local install path
4. document the registry dependency clearly in install docs if intentional

## Notes

This report is specifically about the gateway/bootstrap problem.

There is a separate runtime issue in this same environment involving `qwen3:30b-a3b` reasoning responses and OpenClaw reading only `message.content`, but that is a different bug and should be filed separately.