adapter-openclaw: gateway health-monitor reports dkg-ui channel 'restarting (reason: stopped)' every ~10 min on a running bridge

[Jurij89]

Problem

The gateway log shows recurring entries:

health-monitor [dkg-ui:default] health-monitor: restarting (reason: stopped)

These appear roughly every 10 minutes on a node where the dkg-ui channel bridge is healthy and serving traffic (verified by working chat round-trips through both the Node-UI and Telegram).

The adapter exposes two probe endpoints:

1. GET /api/dkg-channel/health registered on the gateway with auth: 'gateway' (DkgChannelPlugin.ts:507-515) → returns { ok: true }.
2. GET /health on the standalone bridge server (DkgChannelPlugin.ts:1594-1598) → requires bridge-auth, returns { ok: true }.

The bridge listens on port 9201 by default. On gateways that themselves bind 9201 (issue #272), the bridge falls back to an OS-allocated port and the actual port surfaces via transport.bridgeUrl set on the daemon transport descriptor (DkgNodePlugin.ts:1317).

Likely causes (need investigation)

1. Probe targets the bridge endpoint with stale port info. If the gateway's health-monitor probes the configured port (9201) rather than transport.bridgeUrl, it gets a refused-connect on the fallback path and reports 'stopped'.
2. Probe targets /api/dkg-channel/health but the auth context is wrong. The route is auth: 'gateway'. If the monitor probes from an internal context that doesn't carry gateway auth, it gets 401 and treats it as 'stopped'.
3. Probe targets the bridge's /health but lacks the bridge auth token. Same shape as above.

Impact

Likely benign in practice — chat traffic works — but the recurring 'restarting' line is concerning if it's actually triggering a restart of any subsystem. Needs daemon-side / gateway-side investigation to know whether the warn is paper-only or whether the monitor is actually cycling something.

Suggested investigation

1. Identify which endpoint the gateway's health-monitor probes for dkg-ui:default. Trace from the monitor source to the request URL it issues.
2. Confirm whether the monitor is auth-aware (does it inject the gateway internal token / the bridge auth token?).
3. If the monitor is probing the configured port without honoring transport.bridgeUrl, the fix is on the monitor side — read the live transport descriptor.
4. If the monitor is probing the gateway-side route without auth, our fix is on the adapter side: register a second route (e.g. /api/dkg-channel/health/probe) with auth: 'public' returning the same { ok: true }.

Context

Surfaced during PR #264 live-test triage. Filed as post-merge follow-up.