test(e2e): run the edge tunnel test over TLS

[politerealism]

Summary

ws_tunnel_status_through_edge_proxy returned early, and so reported success, whenever it could not set up its own preconditions. In every lane that starts its own gateway it could not, so it never exercised the WebSocket tunnel. This makes it work against a TLS gateway, makes it fail when it can't, and moves it behind a feature flag so it only runs where the gateway supports it.

Related Issue

Contributes to #3712. No separate issue: this is a test-only change that fixes a false pass.

Changes

• Read the gateway endpoint from the registered gateway metadata, instead of scraping gateway info. The old lookup never matched, because the URL is on the Server: line.
• The CLI only tunnels over https://, so the old plaintext requirement could never have exercised the tunnel. The test now needs an https:// gateway and fails with a clear message otherwise.
• For a gateway with a registered CA, point the CLI at it with SSL_CERT_FILE, because the tunnel client uses the system trust store. With no registered CA it uses the system store.
• Replace the silent early returns with failures. The test also requires the CLI's debug log to show WebSocket connected to edge, so a healthy status that bypassed the tunnel cannot pass. This is the one place that depends on a diagnostic line, which RFC 0016 discourages for conformance tests.
• Add an e2e-edge-tunnel feature, enabled by e2e-docker and e2e-podman. Kubernetes and VM can't exercise the test, so they no longer compile it. gateway_status_reports_healthy still runs everywhere.

Testing

• mise run pre-commit passes
• OPENSHELL_E2E_PODMAN_TEST=edge_tunnel_e2e mise run e2e:podman on rootless Podman with a TLS gateway and the tunnel enabled: both tests in edge_tunnel_e2e pass.
• Negative controls on the same gateway: the test fails with UnknownIssuer when the CA isn't trusted, fails at the health precondition for a bad gateway, still passes with an inherited RUST_LOG=warn, and a direct status without the tunnel exits 0 but has no handshake line.
• Not run: the Docker lane (no Docker on my machine) and macOS. SSL_CERT_FILE is read before the platform store in the locked rustls-native-certs (0.8.3), so it should behave the same on macOS.

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (not applicable)

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[politerealism]

@elezar a few things I'd like your eyes on, in case you have time.

1. Docker and macOS. I could only run this on rootless Podman. If you can, could you try it on Docker (OPENSHELL_E2E_DOCKER_TEST=edge_tunnel_e2e mise run e2e:docker) and on a Mac? The Mac part is the SSL_CERT_FILE trust handling, which I expect to work but haven't seen.
2. Feature gate. The test needs a gateway with the tunnel enabled, so I put it behind e2e-edge-tunnel, which e2e-docker and e2e-podman enable. That looks like a feature test under RFC 0016, but I'd like to hear if you'd rather have it somewhere else. test(conformance): move scenario files into Cargo tests #4120 owns the layout, so I haven't pre-empted it.
3. Log assertion. Requiring the CLI's debug log line is the one place this leans on a diagnostic. Without it, a CLI regression that stopped using the tunnel could still pass. I can drop it if you prefer.
4. Plaintext endpoint mode. The lane scripts document OPENSHELL_GATEWAY_ENDPOINT=http://… for reusing an existing plaintext gateway. A full-suite run in that mode now fails this test, with a clear message, because plaintext can't use the tunnel. I found nothing in CI that uses that mode. Should the lane scripts drop the feature in endpoint mode?