`codex exec-server --remote` registration omits `User-Agent` header

[imryao]

Summary

When codex exec-server runs in --remote mode, the two outbound calls to the environment registry / rendezvous travel without a User-Agent header:

1. POST {base_url}/cloud/environment/{environment_id}/register — uses reqwest::Client::new() (codex-rs/exec-server/src/remote.rs:41 on rust-v0.133.0), which does not set a default UA.
2. connect_async(rendezvous_url) — uses tokio-tungstenite's default handshake, which does not set one either.

This is the only outbound path in codex that omits the UA. Every other outbound HTTP call already routes through codex_login::default_client::get_codex_user_agent() — see codex-rs/backend-client/src/client.rs:174 (ClientBuilder::user_agent(...)) and codex-rs/app-server/src/request_processors/initialize_processor.rs:140 (process-global UA suffix set during initialize).

Why it matters

For server-side observability — release-health stats, version-distribution telemetry, debugging connection issues — the upstream registry can't tell which codex version / OS / architecture is connecting from headers alone. The only identifying signal is whatever the auth token's claims carry.

Proposal

Mirror backend-client's pattern in exec-server:

• Replace reqwest::Client::new() with reqwest::Client::builder().user_agent(get_codex_user_agent()).build().
• Wrap the rendezvous URL in an http::Request with a User-Agent header and pass that to connect_async.

No protocol changes, no server-side change required (unknown headers are ignored). Resulting UA shape matches what backend-client already sends:

codex_cli_rs/<ver> (<os> <os_ver>; <arch>) tungstenite-rs/<ver>

Happy to send a PR — branch is ready locally if there's interest. Wanted to surface as an issue first to confirm the team would accept this kind of change before opening one.

[yui-stingray]

Checked this against current main (8a94430). The remote exec-server path still appears to be the outlier described here: EnvironmentRegistryClient::new builds its registry client with reqwest::Client::new(), and run_remote_environment connects to the rendezvous URL with connect_async(response.url.as_str()), so neither call site is currently wired through the shared get_codex_user_agent() path.

The smallest test hook I see is the existing register_environment_posts_with_auth_provider_headers coverage in codex-rs/exec-server/src/remote.rs; extending that to assert a User-Agent on the registry POST would cover half of the regression. The websocket side likely needs a request-building helper so the handshake header can be unit/integration tested without changing the relay protocol.