Fix WhatsApp pairing to show actionable recovery instead of a raw exception (#957)

[karkarl]

Fixes #957.

Problem

Starting WhatsApp QR pairing from the Channels page, against a connected gateway that has no web-login provider loaded, failed by dumping a raw System.InvalidOperationException plus a .NET stack trace containing internal CI build paths (D:\a\openclaw-windows-node\...) to a non-technical user — instead of actionable recovery.

Root-cause ownership (verified — a real Windows-node UX defect, not a WhatsApp-API workaround)

• The string "web login provider is not available" exists nowhere in this repo — it is gateway-generated and only relayed by the node.
• Flow: the gateway replies { ok: false, error: "web login provider is not available" }; OpenClawGatewayClient wraps that message in an InvalidOperationException; WebLoginStartAsync caught it and stored RawResponse = ex.ToString() — the full .NET stack trace with build-machine paths seen in the issue screenshot.
• WhatsApp QR/web-login runs entirely gateway-side, so provider-loading itself cannot be fixed from this repo. The two genuine node-owned defects fixed here are: (1) leaking a relayed internal exception + stack trace into user-facing UI, and (2) no translation of the known gateway signal into recovery.

Changes

• OpenClaw.Shared/ChannelsSnapshot.cs — WebLoginStartResult gains two computed detection properties, mirroring the existing ChannelStartResult.LooksLikeMissingPlugin pattern:
  • LooksLikeMissingWebLoginProvider — provider not loaded → guide the user to install the provider on the gateway host.
  • LooksLikeWebLoginUnsupported — gateway doesn't implement the web.login RPC at all → guide the user to upgrade the gateway (installing a plugin wouldn't add the missing method).
• OpenClaw.Shared/OpenClawGatewayClient.cs — WebLoginStartAsync/WebLoginWaitAsync catch blocks now surface ex.Message (the clean gateway reason) instead of ex.ToString(), so no internal stack trace / CI build paths reach the UI.
• OpenClaw.Tray.WinUI/Pages/ChannelsPage.xaml.cs — the linking flow routes the two detected states to distinct, actionable recovery UIs (a copyable openclaw plugins install @openclaw/<channelId> command with a Copy button, or upgrade guidance) with a non-actionable-exception headline, and keeps the clean gateway detail available in the collapsed "Why isn't this working?" diagnostic.

Validation

• ./build.ps1 ✅
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore ✅ (2772 passed, 31 skipped)
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore ✅ (1709 passed)
• New tests: ChannelResultTests.WebLoginStartResultTests (both detection properties, including cross-classification checks) and ChannelsPageWebLoginRecoveryContractTests (source-contract: both properties referenced, recovery-command affordance present, actionable headline present, and the web-login region contains no RawResponse = ex.ToString()).
• Adversarial closeout review (built-in code-review agent; codex/claude/pi CLIs are not installed on this host): no significant issues — confirmed no remaining stack-trace/CI-path leak, mutually-exclusive recovery routing, sound recovery-panel/clipboard/dispatcher lifecycle.

Real behavior proof

• Automated proof (current head): the Shared detection tests exercise the exact issue string ("web login provider is not available") and assert it maps to LooksLikeMissingWebLoginProvider and NOT LooksLikeWebLoginUnsupported; the Tray source-contract test asserts the linking flow renders the recovery affordance and that the web-login catch region no longer emits ex.ToString().
• Live-gateway UI capture: Not verified / blocked. Rendering the actual WinUI recovery screen requires a live gateway that returns web login provider is not available for web.login.start — a gateway-host provider state that cannot be reproduced from this repo/host. Manual repro: connect the tray to a gateway whose WhatsApp web-login provider is not loaded, open Channels → WhatsApp → Show QR. Expected: headline "WhatsApp linking isn't available on this gateway yet — see how to enable it below.", a recovery panel with a copyable openclaw plugins install @openclaw/whatsapp command + Copy button, and the raw gateway detail available only under the collapsed diagnostic (no System.InvalidOperationException / stack trace / D:\a\... paths in the headline).

Co-authored-by: Copilot App 223556219+Copilot@users.noreply.github.com