#23690: fix(gateway): subagent sessions fail with pairing required on loopback (#23661)

## Summary Subagent sessions can't connect to loopback gateways — they hit "pairing required" (1008) on scope upgrades. The `requirePairing` function only auto-approves "not-paired" reasons for local clients, so scope-upgrade requests get rejected even on 127.0.0.1. Closes #23661 lobster-biscuit ## Root Cause `requirePairing` in `message-handler.ts` sets `silent: isLocalClient && reason === "not-paired"`. When a subagent calls `callGateway({ method: "agent" })`, it goes through `callGatewayLeastPrivilege` which requests `["operator.write"]`. If the device was paired before scopes existed (empty `pairedScopes`), the handler hits the `pairedScopes.length === 0` branch and calls `requirePairing("scope-upgrade")` — which isn't auto-approved on loopback. This was introduced by `0bda0202fd` (security hardening, 2026-02-19) which tightened `silent: isLocalClient` to `silent: isLocalClient && reason === "not-paired"`. ## Changes - Before: only "not-paired" pairing requests are auto-approved on loopback; scope upgrades require manual approval (which never appears in `nodes pending`) - After: both "not-paired" and "scope-upgrade" are auto-approved on loopback; role upgrades still require explicit approval ## Tests - Updated `requires pairing for scope upgrades` — now expects auto-approval on loopback - Updated `rejects scope escalation from legacy paired metadata` → renamed to `auto-approves scope escalation from legacy paired metadata on loopback` - Added `auto-approves scope upgrade on loopback for legacy paired device` — pairs with `operator.read`, strips scopes, reconnects requesting `operator.write`, expects success - All 37 tests in `server.auth.test.ts` pass - `pnpm build && pnpm check` pass <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR fixes a regression where subagent sessions connecting to loopback gateways would fail with "pairing required" (1008) when requesting scope upgrades. The fix changes the auto-approval logic from only allowing `not-paired` requests to allowing both `not-paired` and `scope-upgrade` requests on loopback connections (127.0.0.1). **Key changes:** - Modified `message-handler.ts:641` to change `silent: isLocalClient && reason === "not-paired"` to `silent: isLocalClient && reason !== "role-upgrade"` - Updated existing tests to expect auto-approval for scope upgrades on loopback - Added new test case for legacy paired devices requesting scope upgrades **Security posture:** The change relaxes security only for loopback connections. Role upgrades still require explicit approval even on loopback, maintaining the important security boundary. Scope upgrades within the same role are now auto-approved on loopback, which is appropriate for local trusted connections and fixes the subagent connectivity issue. <h3>Confidence Score: 4/5</h3> - This PR is safe to merge with low risk - it fixes a legitimate regression while maintaining security boundaries - The change is well-targeted and fixes a specific regression introduced by commit `0bda0202fd`. The security relaxation is limited to loopback connections only, which is appropriate. Role upgrades still require manual approval, maintaining the critical security boundary. Test coverage is comprehensive with three test cases updated/added to verify the behavior. However, the score is 4 rather than 5 because this is a security-sensitive change that relaxes access controls, and while the change appears correct, any modification to authentication/authorization logic warrants extra scrutiny in production. - No files require special attention - both files have appropriate changes with good test coverage _{Last reviewed commit: 1a9d19a} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->