CLI: allow specifying a template version for stop/start builds and both legs of coder update #29100

🤖 This issue was filed by Coder Agents on behalf of @Emyrk.

Problem

CreateWorkspaceBuildRequest already accepts template_version_id, but the CLI never sets it for an existing workspace. There is no way to say "build this workspace against version X" from coder stop, coder start, or coder update — the only CLI escape hatch is coder create --template-version, which is limited to new workspaces.

That matters because the version a build renders against is not always the one you want:

• coder stop posts a build with no template_version_id, so wsbuilder.getTemplateVersionID() falls through to "default is prior version".
• coder update stops first (bug: template upgrade fails on claimed prebuilt workspace #17840) and then starts on the template's active version. The stop leg therefore always renders against the workspace's current (possibly bad) version, and the start leg can only target active.

In #29099 this is the mechanism that makes data loss survive an upgrade: the stop leg re-renders parameters against a template version whose module cache was purged, persists a truncated parameter set, and the following start build inherits it even though the target version is healthy. Operators are pushed to hand-rolled curl calls against /api/v2/workspaces/{id}/builds to work around a CLI gap.

Ask

1. coder stop --template-version <name> — pin the version used for the stop build.
2. coder update --template-version <name> — pin the version used for the start leg, instead of implicitly using the template's active version.
3. coder update should also let you control the version for its stop leg, since today it is implicitly the workspace's current version.
4. coder start --template-version <name> for symmetry, which also gives a supported way to do a pinned start build on a running workspace without a stop.

Resolution should match coder create --template-version (version name within the workspace's template, resolved to an ID), and inherit the existing permission behaviour — pinning a non-active version with require_active_version set requires template update permission.

Open design question

For coder update, what should the stop leg default to?

• Current behaviour: the workspace's existing version. Preserves the intent of bug: template upgrade fails on claimed prebuilt workspace #17840, where the stop must run against the version that created the resources so ignore_changes templates tear down correctly.
• Alternative: the version being updated to. Avoids rendering against a stale or broken version, but changes teardown semantics.

I lean toward keeping the current default and adding explicit flags, with a separate flag for the stop leg (--stop-template-version?) rather than overloading one flag for both legs. Naming and defaults are worth a decision before implementation.

Notes

• No API change required; this is CLI plumbing onto an existing field.
• Docs to regenerate: docs/reference/cli/{stop,start,update}.md plus the cli/testdata/*.golden files.