Remove dormant TLS certificate-verification bypasses

[jdevera]

Remove dormant TLS certificate-verification bypasses

Summary

Four HTTP helper branches set tls.Config.InsecureSkipVerify when
ResolveUrl reports that it rewrote a URL:

• internal/helper/http.go: HttpEtag
• internal/helper/http.go: HttpGetWrapper
• internal/helper/http.go: HttpNewRequestWrapper
• internal/helper/file-loader.go: DownloadFileFromUrl

ResolveUrl currently always returns (url, false), so these branches are
not reachable in the current code. This is therefore a dormant security risk,
not evidence that current releases disable TLS verification.

Security impact if reactivated

If URL resolution were restored or changed to return true, a network
attacker could impersonate HTTPS endpoints used for:

• remote configuration;
• package registry indexes;
• package archives;
• explicitly installed package URLs;
• self-update metadata and binaries.

Those resources influence executable content installed or run by the
launcher. The assignments in http.go are especially broad because they
mutate http.DefaultTransport process-wide and persist for later requests.

Historical context

The initial implementation used dscacheutil on macOS to resolve internal
VPN hostnames and replaced the URL hostname with the resulting IP address.
That breaks normal certificate hostname validation, so the code disabled
verification when a URL was rewritten. Commit 699aad0 disabled that resolver
the following day, and a later cleanup reduced ResolveUrl to a constant
false result without removing the insecure branches.

Proposed correction

• Remove the abandoned ResolveUrl mechanism.
• Remove all InsecureSkipVerify branches and unused TLS imports.
• Delete HTTP helpers that have no callers instead of retaining dormant code.
• Add a regression test proving that HTTPS with an untrusted certificate is
  rejected.

If custom DNS resolution is needed later, retain the original hostname for
SNI and certificate verification while customizing only connection dialing.
If private certificate authorities are needed, trust an explicit CA bundle
instead of disabling verification.

Acceptance criteria

• No production code sets InsecureSkipVerify.
• Active HTTP download paths continue to use normal certificate validation.
• An untrusted local HTTPS server is rejected by a deterministic test.
• Existing unit and black-box suites pass.