fix(openclaw-adapter): start HTTP server before core.init() to unblock viewer at startup

[34262315716]

Closes #1841 (OpenClaw adapter portion)

Summary

Reorders the OpenClaw adapter startup sequence in adapters/openclaw/index.ts so the HTTP viewer server binds its port before core.init() runs. core.init() is now a fire-and-forget background task.

This is the same fix as PR #1842 but applied to the OpenClaw adapter (adapters/openclaw/index.ts) instead of the Hermes daemon (bridge.cts).

Problem

In the OpenClaw adapter, the startup sequence was:

bootstrapMemoryCoreFull -> await core.init() -> startHttpServer -> return

core.init() performs orphan episode recovery including recoverDirtyClosedEpisodes(), which calls the LLM to rescore each dirty episode. Under API rate limiting, this can block for minutes.

Since the HTTP server starts after init, the viewer port (:18799) remains unresponsive during this time. Users see a blank page or connection refused when opening the viewer immediately after an OpenClaw restart.

Fix

// Before (broken):
bootstrapMemoryCoreFull -> await core.init() -> startHttpServer -> return

// After (fixed):
bootstrapMemoryCoreFull -> startHttpServer -> void core.init() -> return

1. HTTP server starts first, responding to /api/v1/ping and /api/v1/health immediately
2. Bridge and telemetry setup are unchanged (they don't depend on init)
3. core.init() runs as a background task (core.init().catch(...))
4. If init fails, the viewer continues serving cached data in degraded mode

Why this is safe

• /api/v1/ping returns a hardcoded response — no core state needed
• /api/v1/health calls core.health() which returns ok: false before init — the viewer can show a starting-up state
• All viewer data endpoints read from SQLite, which is fully bootstrapped by bootstrapMemoryCoreFull() before either step
• Bridge hooks (before_prompt_build, agent_end, etc.) call ensureLive() which only checks shutDown, not initialized — turns can proceed concurrently with background init
• Background orphan recovery processes old episodes; new turn events create new episodes — no conflict

Changes

File	Change
apps/memos-local-plugin/adapters/openclaw/index.ts	Move startHttpServer before core.init(), run init as background task

Testing

1. Viewer starts immediately: After restarting OpenClaw, curl http://127.0.0.1:18799/api/v1/ping should respond within seconds, even before init completes
2. Init runs in background: Check ~/.openclaw/memos-plugin/logs/ for background core.init() completed or background core.init() failed after a delay
3. No duplicate processes: Unlike the daemon case (fix: Daemon viewer fails to start when core.init() blocks on dirty episode rescoring — triggers zombie process avalanche #1841), OpenClaw's plugin loader doesn't spawn duplicate processes, but the viewer port is now responsive immediately
4. Data available: The overview page shows cached data from previous sessions immediately; new data from background init appears as it completes

Ref: #1841, #1842