test(channels): isolate WS assertions from initial loading

[n30nex]

Fixes #2086.

The #1468 WebSocket browser checks could fail when initial channel loading completed between their separate before/after evaluations. An orphan message added no channel, yet unrelated loading changed the count from 0 to 5; the positive control could also lose its sentinel when loading replaced the list.

Each check now captures before state, processes its packet, and captures after state in one synchronous browser evaluation. All four original assertions and both message payloads are unchanged. This updates one test file only, with no production, dependency or configuration changes.

Validation

• Delayed real API loading reproduces both failures on unchanged master.
• Both corrected checks pass with loading held and with loading completed; each uses one evaluation.
• Parent independently ran the delayed-loading harness and full browser suite: 131 passed, three existing fixture skips.
• All 183 standalone frontend suites passed. Syntax, inventory, whitespace and privacy checks passed.

TDD justification: test synchronization repair only. Existing assertions demonstrate the baseline failure; no production behavior or manufactured failing test was added.

Browser checks used Chromium against unchanged production source. OpenClaw profile/external preflight were unavailable; repository checks ran directly, with a 60-second local navigation budget. Final CI must pass before merge.

[dborup]

This looks like a reasonable way to isolate the test’s intended assertion, but the original failure may also reveal a real production race that is worth tracking separately.

loadChannels() replaces the entire channels array when the initial /api/channels request completes. If a WebSocket message creates or updates a channel while that request is still in flight, the later API response can overwrite the WebSocket state.

Keeping the snapshots and synchronous batch in one browser turn makes this test deterministic, but it no longer exercises that interleaving. I suggest merging this test-only fix while opening a separate issue/PR for reconciling WebSocket channel updates with an in-flight initial channel load.