[Bug]: Packaged nightly omits CORS header on environment descriptor GET #7102

Before submitting

• I searched existing issues and did not find an open duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Install T3 Code Desktop Nightly 0.0.34-nightly.20260815.1101 on macOS.
2. Start pairing a remote environment through either its managed relay URL or a browser-trusted Tailscale HTTPS URL.
3. Observe the desktop pairing request to /.well-known/t3/environment.
4. Open the same pairing URL in the web client as a control.

The desktop failure was reproduced against both remote paths. The user report also says a Windows desktop client was affected, but the diagnostics below were captured on macOS.

Expected behavior

The desktop client should read the environment descriptor and complete pairing. The actual GET /.well-known/t3/environment response should include the same CORS policy as its preflight response, including Access-Control-Allow-Origin.

Actual behavior

Desktop pairing fails before the environment can be added. The endpoint is reachable and returns valid JSON with HTTP 200, but Chromium blocks the cross-origin response because the actual GET omits Access-Control-Allow-Origin.

The web client succeeds with the same pairing URL because it is served from the environment and uses the same origin.

Impact

Major degradation or frequent failure

Version or commit

t3@0.0.34-nightly.20260815.1101

Environment

• macOS desktop client (confirmed)
• Windows desktop client (reported by the same user, not independently diagnosed here)
• Managed relay HTTPS and Tailscale HTTPS (both confirmed)

Logs or stack traces

# Preflight response
OPTIONS /.well-known/t3/environment
HTTP 204
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: authorization, b3, traceparent, content-type

# Actual response
GET /.well-known/t3/environment
HTTP 200
Content-Type: application/json
# Access-Control-Allow-Origin is missing

This is the same response-header mismatch fixed by merged PR #2594 for #1928. PR #2594 added ACAO to the actual environment/auth responses and regression tests, so its absence in this nightly suggests the packaged distribution artifact may not contain or execute the fixed server response path even if source-level tests pass.

Please test the packaged desktop/CLI dist artifact, rather than only the source server test harness, by making a cross-origin descriptor GET and asserting ACAO on the actual 200 response.

All pairing tokens, environment IDs, private hostnames, relay IDs, and local paths have been omitted.

Workaround

A loopback Caddy proxy that forwards to the remote HTTPS endpoint and adds Access-Control-Allow-Origin: * to responses makes desktop pairing succeed. Removing that header injection reproduces the failure, confirming the missing response header is causal rather than a relay, DNS, or reachability problem.