fix: Synchronize SSH timeouts to 20s to prevent premature connection drops

[eduardomozart]

📋 Description

Currently, SSH connections that require longer cryptographic handshakes (such as connecting to legacy equipment that utilizes slow DH GEX math) are failing prematurely. This is caused by mismatched timeout limits across the application stack:

1. server/routes/term.js enforces a strict 5000ms (5-second) timeout for all incoming terminal WebSocket connections.
2. The underlying ssh2 library defaults to a readyTimeout of 20,000ms (20 seconds).

Because ssh2 was defaulting to 20 seconds, and the WebSocket router (term.js) was hardcoded to 5 seconds, the application was tearing down the session long before the 30-second wrappers in jumpHostHelper.js or ConnectionService.js ever got a chance to finish waiting for those slow legacy handshakes.

Because these limits are lower than the time it takes to negotiate some complex key exchanges, valid connections are being aggressively killed with a Connection timeout, removing session warning before the handshake completes.

Changes

This PR synchronizes the SSH timeout limits across the stack to a standard 20 seconds (20,000ms), aligning them with the existing ssh2 library.

1. server/routes/term.js: Conditionally increased the waitForConnection timeout to 20,000ms specifically for the ssh protocol. Other protocols (like telnet and pve-lxc) retain the fast 5000ms timeout.

🚀 Changes made to ...

• 🔧 Server
• 🖥️ Client
• 📚 Documentation
• 🔄 Other: ___

✅ Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have looked for similar pull requests in the repository and found none
• This pull request does not contain translations (translations are managed through Crowdin)

🔗 Related Issues

#1227

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud