fix(proxy): opt-in console TLS so OIDC works

[kazmosahebi]

Fixes #207

OIDC sign-in could not complete on a Compose stack reached by hostname: the engine's cookies are Secure outside a dev posture while dfe-proxy served plain HTTP, and the engine built an http:// callback because it did not trust the proxy's X-Forwarded-Proto.

DFE_PROXY_TLS=true (default false) chains docker-compose.tls.yml:

• Both proxies serve TLS 1.2-1.3 from certs/console.crt and console.key, using config/proxy/*.tls.yaml. A test holds those equal to the plain configs outside their TLS blocks. The HyperDX ports also keep plain HTTP for in-network callers.
• The network is pinned (DFE_NETWORK_SUBNET, default 10.207.0.0/24), dfe-proxy gets a static address and dfe-engine trusts only that address, never the bridge gateway.
• make refuses to start on a missing, symlinked or mismatched cert and key, an http origin, a subnet that overlaps another Docker network, a dial flip without make down and the auth profile (oauth2-proxy has no TLS yet).
• On every stack, make now refuses an origin that carries a port or path, since Compose appends the port itself.
• make check-proxy validates all four Envoy configs (pinned image, matching dfe-infra's version) and runs in CI.

With the dial off, docker-compose.yml and both plain proxy configs are unchanged.

Tested: make check-hardfail, check-docs and check-proxy pass, ruff is clean and 931 tests pass. On a live stack with an Okta provider, OIDC sign-in completed over https://<hostname>:3000 with TLS 1.3 (X25519MLKEM768, AES-256-GCM). The callback returned 303 and the engine logged the real client address. Not tested: rootless Docker and the new CI step on the runner.