fix(site): use server-side workspace restart orchestration - #28034

Migrates the web UI restart flow to the server-side restart orchestration API added in #25757-#25759 (#5800). Closes DEVEX-758.

Changes

API.restartWorkspace previously orchestrated a restart client-side: POST a stop build, poll it to completion, then POST a start build pinned to the previous template version and poll that too. If the browser tab went away mid-restart, the workspace stayed stopped.

Now it sends a single build request: transition: "stop", reason: "dashboard", and on_success: { transition: "start", rich_parameter_values }. The server persists the follow-up start intent atomically with the stop build and creates the start build after the stop succeeds, so the restart survives the client. The client keeps waiting for display only (the React Query mutation still spans the whole cycle, preserving the "Restarting" button state): it waits for the stop build, then discovers the server-created child build at build_number + 1 (tolerating 404s for up to 60s), then waits for it.

Behavior change: the request omits on_success.template_version_id because pinning requires template-update permission, so the follow-up start uses the template's active version at start time. Restarting an outdated workspace therefore also updates it; the restart confirmation dialog now says so when the workspace is outdated.

Testing

• New restartWorkspace unit tests: single POST shape with on_success, canceled-stop bail, 404-tolerant child discovery, 60s timeout with in-flight request cancellation (red-green verified against the old implementation).
• Remote dogfood UAT passed on this exact head: one build POST per restart (payload verified via devtools), stop then orchestrator-created start in build history, "Restarting" state through the full cycle, and schedule-page apply-now restart.

Known follow-ups (out of scope):

• WorkspaceParametersPage still uses its own client-side stop-then-start flow when saving parameter changes on a running workspace; it can migrate to on_success.rich_parameter_values in a separate PR.
• The API does not expose orchestration status, so when the server permanently fails to create the follow-up start build (for example, stored parameters that are invalid for the active template version), the UI can only report an actionable timeout after the discovery deadline. Exposing the orchestration's terminal error is a backend change that would let the dashboard fail fast.
• The same missing surface means the client discovers the child build by number (stop.build_number + 1) for display. If another client creates a build in the window between stop success and orchestrator processing, the display wait can track that unrelated build. The wait is display-only (workspace state stays correct); exposing the orchestration's child build ID would remove the heuristic.

Mux acted on Mike's behalf to create this PR.