#14277: fix(CLI): Use wss for probeUrl, when gateway has tls enabled

## What does this PR fix? This PR fixes the probeUrl used when the gateway has TLS enabled. Without this PR the command `openclaw gateway status` reports the following problem when used on a gateway with TLS enabled: ``` <...> Probe target: ws://10.23.42.157:18789 <...> RPC probe: failed RPC target: ws://10.23.42.157:18789 gateway closed (1006 abnormal closure (no close frame)): no close reason Gateway target: ws://10.23.42.157:18789 Source: cli --url Config: /home/openclaw/.openclaw/openclaw.json Port 18789 is already in use. - pid 2076 openclaw: openclaw-gateway (*:18789) - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port. <...> ``` With this PR applied, the probeUrl uses "wss" as protocol when TLS is enabled and the `openclaw gateway status` command reports no errors. A small but safe PR for fixing a real problem some users have. <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> Fixes `openclaw gateway status` failing when TLS is enabled on the gateway. The probe URL was hardcoded to use `ws://`, causing connection failures (abnormal closure 1006) when the gateway expects `wss://`. The fix reads `daemonCfg.gateway?.tls?.enabled` and selects the appropriate scheme, consistent with how `src/gateway/call.ts` already handles this. <h3>Confidence Score: 5/5</h3> - Safe to merge — minimal, well-scoped bug fix that follows existing patterns. - Single-file, 3-line change that adds TLS-aware scheme selection. The pattern (`daemonCfg.gateway?.tls?.enabled === true`) is identical to how the core `callGateway()` function already handles this. No risk of regression for non-TLS users since the default path remains `ws://`. - No files require special attention. <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->