fix: scope machine-only settings to application (#1032)

[EhabY]

Summary

Changes these settings from "scope": "machine" to "scope": "application" (all keep ignoreSync: true, unchanged from before, so Settings Sync behavior for them doesn't change):

• coder.binarySource
• coder.binaryDestination
• coder.headerCommand
• coder.tlsCertFile
• coder.tlsKeyFile
• coder.tlsCaFile
• coder.tlsAltHost
• coder.tlsCertRefreshCommand
• coder.proxyLogDirectory
• coder.proxyBypass (deprecated in favor of http.noProxy)
• coder.sshConfig
• coder.sshFlags
• coder.globalFlags

We considered letting a few of these (plain URL/hostname/flag settings with no filesystem path) start syncing now that they're application-scoped, but held off: values like a custom download URL, a TLS hostname override, a proxy no_proxy list, or CLI flags can still be tied to a specific machine's network or environment even without being a literal path, and none of them synced before. That's a separate, deliberate change with its own discussion, not something this scope-resolution fix needs. So every setting here keeps its exact pre-existing sync behavior; only the local-vs-remote read scope changes.

Why

machine scope was introduced in #965 (SEC-200) to stop workspace and folder settings.json from overriding these settings. That security goal still needs to hold, and application scope keeps it: it can only be set in User settings, never overridden by workspace or folder settings.

The reporters in #1032 confirmed that machine scope also causes VS Code to stop honoring the User-configured value when reconnecting to a previously connected remote workspace. First connection works, reconnecting fails, even though nothing in the settings changed. Two independent users confirmed a test build with application scope fixes this on Windows 11, and pin the regression to v1.14.6, the exact release that shipped #965.

All of these settings are read at the same point during the extension's pre-connection setup, right before the SSH connection is established, so they share the same exposure. Array-typed settings (sshFlags/globalFlags) carry the same risk as the string ones: VS Code's scope resolution operates on the setting key regardless of value type (confirmed with a minimal test extension).

The VS Code mechanism

VS Code's WorkspaceService builds a window's local user configuration with a scope filter (getLocalUserConfigurationScopes in configurationService.ts). Once a window has a remote authority, machine-scoped keys are dropped from that filter (LOCAL_MACHINE_SCOPES excludes MACHINE; see configuration.ts). A machine-scoped value can then only come from the remote machine's settings file, not the local one where the user actually configured it.

This is deliberate, long-standing VS Code design, not a recent VS Code change:

• microsoft/vscode-remote-release#2: "machine settings scoped to a machine ... it makes sense to not to respect local machine settings configured in user settings in a remote window."
• microsoft/vscode#177502: the VS Code team hit this exact problem for a remote-authority resolver reading http.proxy (a machine-scoped setting) before/during connection setup, and fixed it the same way we are here: "Made proxy settings application scope by default. Once connected to remote, scope is changed accordingly."
• VS Code's own unit test asserts this exact behavior unconditionally for any remote window, no reconnect needed: configurationService.test.ts, suite WorkspaceConfigurationService - Remote Folder, test machine settings in local user settings does not override defaults. It writes a machine-scoped key to the local user settings.json, constructs WorkspaceService with a remoteAuthority, and asserts getValue() returns the default, not the configured value.

We verified this ourselves by building VS Code from source and adding a test using our exact setting: writing {"coder.binaryDestination": "/usr/bin/coder"} to the local user settings.json, constructing WorkspaceService with a remoteAuthority, and confirming inspect('coder.binaryDestination').userLocalValue correctly shows /usr/bin/coder (the value IS in the file) while getValue('coder.binaryDestination') returns '' (the default) instead. This test passed on a single fresh connection, no reconnect needed, matching the official suite. So the WorkspaceService-level mechanism is confirmed directly against our own setting, not just VS Code's generic fixture.

So what changed for us wasn't VS Code: it's that v1.14.6 (#965) started using machine scope for these settings for the first time, which activated this pre-existing filtering behavior for settings that had never been subject to it before.

This PR and investigation were assisted by Coder Agents on behalf of @EhabY.