macOS: VS Code 1.131 blocks Local Network access for integrated terminal/Remote-SSH (regression, works on 1.130)

Does this issue occur when all extensions are disabled?: Yes

- VS Code Version: 1.131.0
- OS Version: macOS (darwin arm64) —macOS 26.6 (25G72)
Steps to Reproduce:
1. On macOS, with an app-level "Local Network" permission previously granted to VS Code, open the integrated terminal or use Remote-SSH to connect to a device on the local LAN (e.g. `192.168.1.x`).
2. Observe that any network call to a local/private IP fails at the OS level — e.g. `ping 192.168.1.2` inside the VS Code integrated terminal returns `ping: sendto: No route to host`, and `ssh 192.168.1.2` returns `ssh: connect to host 192.168.1.2 port 22: No route to host`.
3. Run the identical command (`ping 192.168.1.2` or `ssh 192.168.1.2`) in Terminal.app (or iTerm) on the same machine, same network — it succeeds immediately.
4. Confirm this is scoped to VS Code's process tree, not general connectivity or SSH config, since ping (a non-SSH, non-auth-dependent command) fails identically.
5. Downgrade to VS Code 1.130 — same commands, same machine, same network — LAN access works correctly in both the integrated terminal and via Remote-SSH.

Additional context:
- `System Settings → Privacy & Security → Local Network` shows VS Code's toggle in an ambiguous/inconsistent state; toggling off/on and relaunching does not resolve the issue on 1.131.
- `tccutil reset LocalNetwork com.microsoft.VSCode` (and `tccutil reset LocalNetwork` system-wide) fail to reset the permission, including when run with `sudo` and from Recovery Mode.
- Remote-SSH log shows the failure occurring at the OS routing layer before any SSH handshake begins:
`ssh: connect to host 192.168.1.2 port 22: No route to host`
- Suspect a regression in 1.131 related to how the app's Local Network TCC entitlement/entry is being requested or retained, causing macOS to silently deny LAN traffic from VS Code's spawned child processes (integrated terminal shell, Remote-SSH's ssh subprocess) even when the toggle appears enabled.
- Workaround: rolling back to 1.130 restores normal LAN access without any permission changes.