fix: remove stale coder_parameter options from workflow display - #29500

CLIENT-697

Summary

A mutable coder_parameter whose selected option is removed from a template update but used in a workspace build could block further changes.

With this PR it no longer blocks the workspace build. The stale value falls back to the parameter's default, and the substitution is reported as a warning rather than an error.

Problem

When a template update removes an option value that a workspace already selected, the stored value is no longer a member of the option set. coder/preview relays a per-parameter

Any build that supplies no parameter values of its own build's values, so it fails with a 400. That includes autostart and prebuild reconciliation, not just the UI. In the web UI the preview websocket returns the same per-parameter error, which
disables "Update and start"; on a template with required inputs inputs are disabled as well, leaving the user no way to select a valid option or proceed.

The CLI appears unaffected only because it drops invalid options client-side and retries against the active version, so coder ssh masked a server-side failure rather than avoiding it.

Fix

ResolveParameters now drops a carried-forward value parameter's options, letting the existing defaultbackfill supply the new default. Values supplied with the build or by a preset are still validated, since those were asked for explicitly,
and immutable parameters are left alone because replahe immutability check instead. The value is checkedagainst the option set directly because the upstream diagnostic carries no machine-readable code to match on.

The preview endpoints render through RenderReconciled, which re-renders without the dead value and attaches a warning carrying a stale_option code, so the form shows the default option.

The parameters page no longer disables its inputs via ?templateVersionId=, because the build it submits is the update the template requires. Without that query parameter the form stays disabled as before.