fix(windows): make node-pty compat shape-based

[web3dev1337]

Summary

• remove the brittle Windows node-pty version gate and patch ConPTY compatibility by package shape/behavior instead
• fall back to direct conpty.node patching when node-pty/lib/utils.loadNativeModule is unavailable
• add targeted tests covering missing package metadata, mismatched version strings, and direct native-module fallback

Root cause

Recent Windows PTY fixes landed in this sequence:

• fix: harden windows pty startup compatibility #971 introduced a runtime on-disk patch of windowsPtyAgent.js
• fix: use runtime node-pty compatibility shim #972 replaced that with a runtime shim in server/utils/nodePtyCompat.js
• fix(windows): make node-pty compat shim adaptive #975 and fix(windows): patch packaged node-pty connect compat #977 expanded the shim for more ConPTY signatures

The regression is that the current shim assumes two things that are not consistently true across installs:

1. node-pty/package.json reports 1.2.0-beta.12
2. node-pty/lib/utils exposes loadNativeModule

In this checkout, the installed module reports 1.0.0 and lib/utils.js does not expose loadNativeModule, so the current runtime shim can skip entirely even on Windows installs that still need compatibility patching. That explains why behavior can diverge across machines and upgrades.

Notes

• PR fix: restore legacy workspace data fallback #974 (workspace backward compatibility) is not the PTY root cause for this regression.
• The new shim still uses loadNativeModule when available, but no longer depends on it.

Test plan

• node --check server/utils/nodePtyCompat.js
• npx jest tests/unit/nodePtyCompat.test.js --runInBand
• npx jest tests/unit/sessionManager.windowsPty.test.js tests/unit/commanderService.windowsShellArgs.test.js --runInBand
• npm ls node-pty # observed local install reports 1.0.0, demonstrating why exact-version gating is brittle