feat: add ability to attach to devcontainers

[DanielleMaywood]

Relates to coder/coder#16426

Adds the ability to connect to a running devcontainer inside a Coder Workspace.

We add a new handler to handle the URI

vscode://coder.coder-remote/openDevContainer

With the following query params:

• url: The URL of the deployment
• token: The API key
• owner: The workspace owner
• workspace: The workspace name
• devContainerName: The name of the dev container
• devContainerFolder: The folder inside the dev container

[Copilot]

Pull Request Overview

This PR adds functionality to attach to a running devcontainer within a Coder Workspace. The changes include introducing a new utility to build remote authority strings, updating the extension to handle a new "/openDevContainer" path and register a corresponding command, and implementing the openDevContainer command in the commands module.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/util.ts	Adds toRemoteAuthority to centralize remote authority string logic.
src/extension.ts	Introduces new query parameter processing and command invocation for devcontainers.
src/commands.ts	Implements openDevContainer command and refactors openWorkspace to leverage toRemoteAuthority.

[Copilot]

The extension passes a workspaceAgent parameter for the openDevContainer command, but this parameter is being discarded by explicitly setting workspaceAgent to undefined. Consider either using args[2] if provided or updating the extension to no longer supply the parameter.

Suggested change

	const workspaceAgent = undefined // args[2] is reserved, but we do not support multiple agents yet.
	const devContainerName = args[3] as string
	const workspaceAgent = args[2] as WorkspaceAgent | undefined // Use args[2] if provided.

[DanielleMaywood]

We already have precedent for doing this with the openWorkspace flow

[code-asher]

Slick! I only tested VS Code (not Cursor, etc), but it looks good.

[code-asher]

No need to change in this PR since this is a pattern that already existed, but at some point I wonder if we should catch handler errors and show them in an error notification. Currently the only way to see them seems to be to go to the extension's features > runtime status > uncaught errors.