[LemonYangZW]

Summary

Fixes #848.

Linux guest OAuth now always leaves egress selection to the slot's existing kin-eg-* transparent network. It no longer forwards the VM binding URL into kin-oauth-auth.

Root cause

runGuestOAuthAuthService previously sent boundProxyUrl(vm.proxy) unless the binding was px-local. A controller-side SOCKS forwarder stored as 127.0.0.1:20881 was therefore forwarded into the Docker/KVM guest, where loopback points at the guest itself and token exchange failed with ECONNREFUSED.

The slot already joins its bound transparent egress network, and its worker uses an empty proxy_url in that mode. This change applies the same rule to guest OAuth.

Changes

• Send proxy_url: '' to non-native guest OAuth helpers; the macOS native path still returns before this code and keeps its original payload.
• Add a deterministic unit test that mocks prepare / runDocker and verifies both loopback and remote bindings produce an empty guest proxy_url.
• Update the existing binary fixture to assert the production input is empty, then inject its host-local SOCKS fixture only for the subprocess test.

This is complementary to #845: #845 avoids the control-plane bootstrap hop after exchange, while this PR fixes the guest helper input that still carried the unreachable controller URL.

Tests

node --test test/unit/oauth-auth-url.test.mjs test/unit/oauth-binary.test.mjs test/unit/oauth-identity.test.mjs test/unit/guest-oauth-transparent-egress.test.mjs

tests 21
pass 20
fail 0
skipped 1 (openssl unavailable)

• npx biome check on all changed JS tests/source: passed.
• git diff --check: passed.
• No real OAuth, proxy, model, or upstream API requests were made for this change.

Risk

Low. Only the non-native Linux guest helper input changes, from a controller-specific proxy URL to the transparent-network contract already used by slot workers. Native macOS behavior is unchanged.