inline hostname resolution for remote sandbox config (#19739)

# Why

Requirements support host-specific
`remote_sandbox_config.hostname_patterns`, but config loading previously
resolved and passed the system hostname through every config-loading
path even when no requirements layer used `remote_sandbox_config`. On
machines where hostname lookup is slow, startup and app-server config
reads paid for a feature that was not active.

We only need the hostname when a requirements layer actually declares
`remote_sandbox_config`, so this moves hostname resolution to the single
requirements merge point and keeps all other config callers unaware of
hostname matching.

# What

- Removed the eager `host_name` plumbing from
`load_config_layers_state`, `load_requirements_toml`, `ConfigBuilder`,
app-server `ConfigManager`, network proxy loading, and related call
sites.
- Resolve the hostname inside
`merge_requirements_with_remote_sandbox_config` only when the incoming
requirements contain `remote_sandbox_config`.

codex-rs/config/src/loader/macos.rs

@@ -65,7 +65,6 @@ fn load_managed_admin_config() -> io::Result<Option<ManagedAdminConfigLayer>> {
 pub(crate) async fn load_managed_admin_requirements_toml(
     target: &mut ConfigRequirementsWithSources,
     override_base64: Option<&str>,
-    host_name: Option<&str>,
 ) -> io::Result<()> {
     if let Some(encoded) = override_base64 {
         let trimmed = encoded.trim();
@@ -77,7 +76,6 @@ pub(crate) async fn load_managed_admin_requirements_toml(
             target,
             managed_preferences_requirements_source(),
             parse_managed_requirements_base64(trimmed)?,
-            host_name,
         );
         return Ok(());
     }
@@ -89,7 +87,6 @@ pub(crate) async fn load_managed_admin_requirements_toml(
                     target,
                     managed_preferences_requirements_source(),
                     requirements,
-                    host_name,
                 );
             }
             Ok(())