Add command to run a `coder speedtest` against a workspace

[spikecurtis]

coder speedtest tests the end-to-end connection speed of the tailnet tunnel to a workspace. Add this as a command to allow users to diagnose whether any perceived slowness is attributable to the networking.

Scope

Implement a Coder: Speed Test command that:

1. Executes coder speedtest against the currently connected workspace via the CLI.
2. Shows progress using VS Code's progress notification (vscode.window.withProgress) while the test runs (the test takes ~5s by default).
3. Saves the JSON output — after the test completes, present a save dialog (vscode.window.showSaveDialog) so the user can save the JSON results to disk.
4. Optionally open the saved file — after saving, prompt the user with the option to open the file in the editor.
5. The command should use --output json to get structured results.
6. The command should be available in the Command Palette when connected to a workspace.

JSON output format

The coder speedtest --output json command produces structured output like:

{
  "overall": {
    "start_time_seconds": 0,
    "end_time_seconds": 5.04,
    "throughput_mbits": 911.91
  },
  "intervals": [
    {
      "start_time_seconds": 0,
      "end_time_seconds": 1.00,
      "throughput_mbits": 803.03
    }
  ]
}

UX

• Command Palette: Coder: Speed Test
• Progress notification while the test runs.
• Save dialog for the JSON output file after completion.
• Option to open the file after saving.

Follow-up

• ENG-2302 — Proactive slowness detection (prompt users to run this command automatically) and speedtest JSON visualization in a lightweight webview.

[EhabY]

For the UX, should it be a simple Command like Coder: Speed Test? Also where would we output the JSON (potentially we can just show the full output in a terminal and they can copy paste if need be)?

The discussion here would probably also apply to #749

[EhabY]

@code-asher @jcjiang would appreciate some feedback on the UX of #749, #750, #751

[code-asher]

Yeah I think implementing them as commands is the way to go. We can always then later hook up buttons to those commands if we need to make them more discoverable, from the sidebar or something.

For the speed test, what if it asked whether the user wanted it in their clipboard (assuming extensions have access to the clipboard) or as a new file (after which users can then save it to disk, or if we have access to the file save dialog we could create the file directly for them).

Or we just open it as a new file, at which point a user can either save to disk or select all and copy (although unfortunately that would require that they then close the file and say no to the unsaved changes prompt, which could feel a bit janky).

Or do we maybe want to pop open a web view and render the data as a graph right there in the editor (with buttons to view the raw data as a new file or copy it)?

For ping in #749, I think popping open a terminal and running it in there makes a lot of sense, similar to how a build command would work.

And for the support bundle #751 we could also run this in the terminal, might make the most sense since it has some output the user should probably read and we probably want them to answer yes to the confirmation prompt.

[EhabY]

I think showing a save dialog with an option to open the JSON file seems the best here, we can address the visualization in a followup (see #867, I'll write a mini-RFC for it). I've updated this issue and the other log collection issues as well.