DEVEX-586: Auto-fill customization fields from selected base template

Goal

In the Template Builder wizard, the final Customizations step currently renders empty inputs for Display name, Description, ID, and Icon. Pre-populate these with sensible defaults derived from the selected base template, while keeping every field editable. Organization is already auto-selected when a single org is available, so it is out of scope beyond leaving it untouched.

Source: Linear DEVEX-586 (Ben Potter): "Would love if all these options ... were auto-filled and generated and can be edited versus the user manually filling it out." Fields called out: display name, description, ID, and icon.

Current behavior (findings)

Frontend lives in site/src/pages/TemplateBuilder/.

• TemplateCustomizationsStep.tsx renders the four fields bound to state.displayName, state.description, state.name (the "ID" field), and state.icon. All start empty (initialWizardState).
• wizardState.ts holds the state, the wizardReducer, and the SelectedBaseMeta UI type.
  • SelectedBaseMeta did not carry description.
  • toSelectedBaseMeta(base) maps the API TemplateBuilderBase into SelectedBaseMeta.
  • SET_BASE set the base and cleared baseVariableValues only when the base id changed; customization fields were left empty.
  • RESET_CUSTOMIZATIONS (dispatched by handleBack) blanked org/provisioner plus name, displayName, description, icon.
  • initWizardState(preselectedBase) seeded baseTemplateId and selectedBase for deeplinks but left customization fields empty.
• API type TemplateBuilderBase exposes id, name, description, icon, os, variables, prerequisites.
• Backend (coderd/templatebuilder_handler.go) builds each base from the built-in TemplateExample: id = ex.ID, name = ex.Name, description = ex.Description, icon = ex.Icon.
• Base IDs are valid template names (lowercase, hyphen-separated): docker, kubernetes, aws-linux, aws-windows, gcp-linux, gcp-windows, azure-linux, digitalocean-linux, scratch.

Default mapping

Rationale for name = base.id: base ids are guaranteed valid template slugs, whereas slugifying the human display name is lossy and can collide. The field stays editable.

Icon default: confirmed, no map needed

The API already returns normalized, served asset paths in base.icon (e.g. /icon/docker.png, /icon/aws.svg, /emojis/1f4e6.png for scratch), the same values CreateTemplatePage assigns when creating from a built-in example. IconField accepts any URL/path, so every base renders correctly. A base-id-to-icon map is unnecessary.

Implementation

Frontend-only, in wizardState.ts:

1. Add description?: string to SelectedBaseMeta; map it in toSelectedBaseMeta.
2. Add pure helper baseCustomizationDefaults(base) returning { name, displayName, description, icon }.
3. SET_BASE: on base change, spread the defaults alongside the baseVariableValues: {} reset; on same-base re-selection, preserve existing values.
4. initWizardState(preselectedBase): spread defaults into the returned state.
5. Narrow RESET_CUSTOMIZATIONS to reset only organizationId and hasProvisioners.
6. toCreateTemplateRequest already sends the fields, so no payload change.

Tests

Reducer unit tests in wizardState.test.ts for seeding, base-change re-seed, same-base edit preservation, RESET_CUSTOMIZATIONS, initWizardState, toSelectedBaseMeta (description carried), and baseCustomizationDefaults.

Scope / non-goals

• No backend changes; the API already returns all needed fields.
• Organization auto-selection is unchanged.
• No slug transformation of display names (base id is used directly).
• No base-id-to-icon map.