fix: fall back to stdio when pipe startup fails

[chagong]

Fixes #4433.

This adds a guarded startup fallback for the standard language server: when the initial TransportKind.pipe executable does not connect within the 30-second pipe startup timeout, the extension recreates the client with TransportKind.stdio and starts again. This keeps vscode-java resilient while the underlying vscode-jsonrpc path-budget fix in microsoft/vscode-languageserver-node#1804 is pending/released.

Implementation notes:

• The fallback is limited to executable server options using TransportKind.pipe.
• The fallback only handles pipe startup timeout; non-timeout startup failures still propagate normally.
• The fallback does not attempt to terminate the server process from this layer.
• File rename handlers resolve the current language client lazily so they use the replacement client after fallback.
• Added fake-client tests for pipe rejection, pipe timeout, and stdio failure behavior.

Validation:

• npm run compile passed, with the existing webpack warning from vscode-languageserver-types.
• npm run eslint passed.
• git diff --check passed.
• npm test ran the new Standard Language Client Test; all 3 new fallback tests passed. The full suite still fails on the pre-existing/unrelated command registration assertion where java.getFullyQualifiedName is missing from the actual registered commands in this local run.