Support loading prebuilt binary from NODE_PTY_PREBUILT_PATH

[anthonykim1]

Part of: microsoft/vscode#307746

Adds NODE_PTY_PREBUILT_PATH env var — if set, loadNativeModule()
tries that directory first before the usual build/Release → prebuilds/
fallback.

Chat extension bundles copilot sdk, which in turn bundles node-pty with
its own prebuilds. Extension's current workaround is finding vscode's
pty.node at runtime and copying it on top of the sdk's prebuilds dir.

---> nodePtyShim has a bunch of retry loops and polling because the copy can
race. This won't be great if chat moves into core — now we're copying
files inside our own install directory at startup, code signing issues, etc

[anthonykim1]

@deepak1556 Could I get your eye on this please?

[deepak1556]

Having an env way to inject native binding from arbitrary paths is not a good design, it just opens up as easy target to load any binding into the process.

IIUC the motivation is avoid runtime copy of the node-pty module for the sdk when bundled as part of the core. In which case, could you rather remove the node-pty package from sdk during build time, then allow the module to be auto resolved via Node.js default module resolution. If the sdk is part of core, it should eventually end up resolving the module from resources/app/node_modules. Have you confirmed if this is possible ?

[anthonykim1]

@deepak1556 Thanks, that sounds neat for vscode. This would allow us to not change anything from node-pty side.

For other non-vscode consumers of copilot sdk though:
I don't think copilot cli declares node-pty as dependency but rather just bundles pre-built binary. If we were to remove this from build time, then other non-vscode consumer of copilot sdk might fail when copilot sdk code runs require('node-pty'). Maybe we could have special casing that removes it only for vscode?

/cc @rebornix @DonJayamanne @devm33 please correct me for copilot cli sdk matter.