fix: allow ws:// to a loopback Companion from https pages

[k-ross]

Since #707 the Companion WebSocket always uses wss:// on https pages, which breaks the common setup of Companion running on the same machine as the browser, since it serves plain ws://. Browsers treat loopback hosts (localhost, *.localhost, 127.0.0.0/8, [::1]) as potentially trustworthy and allow ws:// to them from https pages, and the traffic never leaves the machine, so use ws:// for loopback hosts and keep wss:// for everything else.

The scheme is still chosen from the page protocol and the validated host, never from an incoming ws:// or wss:// prefix. The protocol prefix shown in the connect and save-preset modals now reflects the host being entered.

[birme]

LGTM — reviewed as part of daily-backlog-pr Phase 3.5 orphan-PR housekeeping (full code-reviewer pass on a clean clone; npm ci/lint/typecheck/test all green, 326 tests).

The security core checks out: the ws:// relaxation is decided only in isLoopbackCompanionHost and is restricted to localhost / *.localhost / 127.0.0.0/8 / [::1] — suffix-confusion hosts (e.g. localhost.evil.com, 127.0.0.1.evil.com) are correctly rejected and covered by tests, and the real connection always flows through buildCompanionWsUrl (fail-safe to wss for anything stricter). No blocking issues.

Non-blocking suggestions for a follow-up (not gating this merge):

• src/utils/call-url.ts:76 — the 127(?:\.\d{1,3}){3} regex doesn't bound octets to 0–255 (harmless, but tightening would match 127.0.0.0/8 exactly).
• A one-line comment noting the *.localhost trust assumption (matches the browser's own model).