Problem

When a coder_parameter has option {} blocks defined, the parameter value is strictly validated against the option set. This creates friction when:

1. Migrating existing workspaces: If a template author removes or changes an option value, existing workspaces with the old value are forced to select a new value before they can update.
2. Deprecating options: There's no graceful way to deprecate an option while still allowing existing workspaces to function.
3. Power users: Some users may need values outside the predefined options while others benefit from the dropdown UI.

Proposal

Add an allow_custom (or similar) attribute to coder_parameter that:

• Keeps the dropdown UI with predefined options for discoverability
• Allows workspaces to retain/use values that aren't in the option set
• Optionally shows a text input alongside the dropdown for custom values

Example

data "coder_parameter" "instance_type" {
  name         = "Instance Type"
  type         = "string"
  allow_custom = true  # New attribute
  default      = "t3.medium"

  option {
    name  = "Small"
    value = "t3.small"
  }
  option {
    name  = "Medium"
    value = "t3.medium"
  }
  option {
    name  = "Large"
    value = "t3.large"
  }
}

Current Workarounds

1. Temporarily add legacy values as options before pushing template updates
2. Use validation {} with regex instead of option {} (loses dropdown UI)
3. Use dynamic parameters to include legacy/custom values programmatically

Additional Context

This would make template evolution smoother and reduce the friction of updating workspaces when option sets change.