NameFieldSettingsTrait - generational

Problem/Motivation

The default autocomplete_source for the generational component in NameFieldSettingsTrait::getDefaultNameFieldSettings() stores the source key generation, but the field settings UI, runtime autocomplete plan builder, and documentation all use generational.

When a name field retains that default (or exported config from an older release), generational autocomplete silently does nothing: AutocompletePlanBuilder::buildAutocompletePlan() only recognizes title and generational as label sources, and generation is not a valid key in the plan’s source map. The field settings form shows the generational source enabled, but the autocomplete endpoint never matches generational suffix options.

This is already called out as legacy config in docs/deprecations.md and docs/services/autocomplete.md; the fix should correct defaults for new fields and migrate existing field_config entities on update.

Steps to reproduce

Install or use a site with a name field whose settings include autocomplete_source.generational: ['generation'] (the shipped default, or config exported before the fix).

Set the generational component’s field type to autocomplete (or rely on a field that merges defaults without re-saving settings).

Create or edit content and type in the generational autocomplete field; query the autocomplete route for generational options (e.g. “Jr.”).

Expected: suggestions from generational_options.
Actual: no generational matches; autocomplete appears broken with no error.

Proposed resolution

1. Fix the default — In src/Traits/NameFieldSettingsTrait.php, change the generational autocomplete source default from ['generation'] to ['generational'] so new fields and code paths that merge defaults get the key the UI and runtime expect.

2. Post-update for existing sites — Add name_post_update_*() in name.post_update.php, modeled on name_post_update_add_autocomplete_match_settings(): load all name field_config entities; read $settings['autocomplete_source']['generational'] when present; replace any generation entries with generational (preserve order, dedupe if both appear); save only when changed; return a count message. Settings live on field_config after name_post_update_field_settings_merge(), so iterate field configs, not storage config.

3. Optional runtime guard — Map generation → generational in AutocompletePlanBuilder::normalizeAutocompleteSettings() for config imported before post-updates run. Keep the post-update anyway so exported config is corrected on disk.

4. Tests

• tests/src/Unit/Traits/NameFieldSettingsTraitTest.php — testDefaultAutocompleteSourcesOnlyOnTitleAndGenerational() expects ['generational'].
• tests/src/Kernel/PostUpdateHooksTest.php — new test: field with ['generation'] migrates to ['generational']; already-correct config untouched.
• tests/src/Functional/NameFieldDataAutocompleteTest.php — two tests set 'generational' => ['generation']; keep as legacy pre-migration scenarios or switch to generational if not testing legacy behavior.

5. Docs — Soften the legacy-config note in docs/deprecations.md once the release number is known (fixed via post-update in name:8.x-1.y).

No hook_update_N(), schema change, or PHP API deprecation is required.

Remaining tasks

• Change default in NameFieldSettingsTrait.php
• Implement post-update hook in name.post_update.php
• Update unit test default expectation
• Add kernel post-update test
• Review/adjust functional autocomplete tests
• Optionally add runtime normalization in AutocompletePlanBuilder
• Update docs/deprecations.md (and optionally docs/services/autocomplete.md) after release is tagged

User interface changes

None. The field settings UI already uses generational; this fix aligns stored defaults and migrated config with what the UI shows.

API changes

None. No public PHP API, service IDs, hooks, or interfaces change. generation was never a documented autocomplete source key.

Data model changes

None. No database or config schema changes. config/schema/name.schema.yml already treats autocomplete source values as generic strings. Existing sites receive a config entity value correction (generation → generational in field_config settings) via post-update only.