fix: queue workspace updates as one build

[EhabY]

Problem

coder update runs a stop build and then a start build. Between the two, the extension's own coder ssh reconnect autostarts the workspace on the old template version, so the update's start build is rejected:

stopped → starting   reason: ssh_connection
"A workspace build is already active"

The workspace restarts on the version it already had, and the extension logs a warning and connects anyway.

Changes

Deployment	Update path
2.36 and later	One stop build that carries the start in on_success, so nothing can take the slot in between
Before 2.36	Unchanged: coder update, or the REST API on CLIs before 2.24

The server owns the slot from the moment the stop build is posted, so a reconnect can no longer jump ahead of the update. template_version_id stays unset on the queued start, because pinning a follow-up build requires template update permission and the update targets the active version anyway. A workspace that is already stopped takes a lone start build, which can name the version.

While the queued build runs, the state machine follows it instead of starting the workspace itself, and it ignores monitor events from older builds.

On a failed update, a modal offers Connect Anyway instead of silently falling back to the old version. Declining aborts the connection.

Feature sets

FeatureSet becomes CliFeatureSet, and a new ServerFeatureSet keys the 2.36 check to the deployment version instead of the CLI's. The Tasks check moves there too, bounded to 2.29 through 2.34, the releases that serve /api/v2/tasks (coder/coder#20921 promoted it out of /api/experimental). Below 2.29 the panel used to show and then 404 on every poll.

Validation

pnpm lint, pnpm typecheck, pnpm format:check, and pnpm test (2,729 passed, 1 skipped, 185 files). No live SSH-race reproduction or Windows smoke test.

Fixes #1095.