Fix launch timeout being applied 1000x longer than configured

[sombraSoft]

A configured launch timeout of 300 seconds actually waits ~3.5 days. InstanceConfiguration.provision() passes getLaunchTimeoutMillis() (seconds × 1000) into the node builder, but ComputeEngineInstance.launchTimeout is documented and consumed as seconds — its own getLaunchTimeoutMillis() multiplies by 1000 again. Every wait that uses node.getLaunchTimeoutMillis() (insert-operation wait, startup-script wait, SSH wait) runs with a timeout 1000× larger than configured.

In production we found 16 Computer.threadPoolForRemoting threads wedged for a week inside ComputeClient.waitForOperationCompletion, polling long-expired GCE operations (404 on every poll), with their nodes stuck offline in "connecting" state and the backing VMs kept alive indefinitely by CleanLostNodesWork label refreshes:

Computer.threadPoolForRemoting [#64] TIMED_WAITING
  com.google.cloud.graphite.platforms.plugin.client.ComputeClient.waitForOperationCompletion(ComputeClient.java:669)
  com.google.jenkins.plugins.computeengine.ComputeEngineComputerLauncher.launch(ComputeEngineComputerLauncher.java:195)
  hudson.slaves.SlaveComputer.lambda$_connect$0(SlaveComputer.java:298)

The fix passes launchTimeoutSeconds to the builder, matching the field's documented unit.

Resolves #560

Testing done

• New unit test InstanceConfigurationTest#testProvisionedNodeLaunchTimeoutIsInSeconds provisions a node from a configuration with a 100-second launch timeout and asserts the node reports 100 s / 100 000 ms. It fails before the fix (expected:<100> but was:<100000>) and passes after.
• Full InstanceConfigurationTest class passes (28/28).
• Verified in a production Jenkins instance (public OpenROAD CI): with the corrected timeout the launcher gives up after the configured 300 s and terminateNode() cleans up, instead of wedging threads for days.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed

[das7pad]

LGTM

(We also discovered this at work today and would love to see this merged.)