Align verbose SSH env handling across SSH connection paths

[Copilot]

The failing test job traced back to inconsistent WHEEL_VERBOSE_SSH handling in the server SSH codepaths. sshManager normalized false-like values, but tryToConnect still treated any non-empty string as enabled.

• Root cause

  • server/app/handlers/tryToConnect.js used a raw truthiness check:
    • "false" and "0" still enabled sshOpt: ["-vvv"]
  • server/app/core/sshManager.js already had the intended normalization logic

• What changed

  • Reused sshManager's isVerboseSshEnabled() helper from tryToConnect
  • Exported the helper from server/app/core/sshManager.js
  • Added focused unit coverage for tryToConnect to lock in behavior for:
    • truthy values
    • false-like values

• Behavioral effect

  • Both SSH entry points now interpret WHEEL_VERBOSE_SSH consistently
  • False-like values no longer inject verbose SSH flags during connection checks

• Example

  // before
  if (process.env.WHEEL_VERBOSE_SSH) {
    hostInfo.sshOpt = ["-vvv"];
  }
  
  // after
  if (isVerboseSshEnabled()) {
    hostInfo.sshOpt = ["-vvv"];
  }