domain_config: Make DomainConfigOverrideEditable::save() write a sparse, cast-aware diff against base

Problem / Motivation

DomainConfigOverrideEditable::save() previously wrote $moduleOverrides verbatim. For per-key set() callers (ConfigFormBase) that worked because each set() populated $moduleOverrides. For setData() callers (ConfigEntityStorage::doSave(), drush, custom code) the in-memory data mutation never reached $moduleOverrides and the changes were silently dropped.

Two side effects of the legacy "write moduleOverrides verbatim" path:

• Setting a previously overridden key back to its base value did NOT drop the key from the override row, leaving stale entries that confuse the override → base diff in config sync.
• Base values stored under an older schema (e.g. a key now typed boolean stored on disk as the string "1") strict-mismatched freshly-cast new values, producing spurious override entries that grew across upgrades.

Proposed resolution

DomainConfigOverrideEditable::save() derives the override row as a sparse diff against base on every save path, with both sides cast through the typed-config schema before the comparison.

1. $base_data becomes a constructor argument on DomainConfigOverrideEditable. The factory passes the override-free base payload at construction time.
2. A new castThroughSchema() helper runs the typed-config schema cast on both $this->data and $base_data before the diff, so values are compared like-for-like.
3. DiffArray::diffAssocRecursive($cast_data, $cast_base) is what lands in $moduleOverrides on every save.
4. updateExistingKeysInNestedArray() is no longer used internally and is deprecated. There is no drop-in replacement in core (different shape than DiffArray::diffAssocRecursive).

The read path is unchanged: loadOverrides() returns the raw stored override; core's Config::setOverriddenData() continues merging via NestedArray::mergeDeepArray.

Known limitation: sequence shrinks

Per-domain overrides on type: sequence configs cannot drop trailing items from base. This matches core's mergeDeepArray semantics across every override mechanism (settings.php, module overrides, …) — it is not a divergence introduced here. Documented in docs/domain_config/index.md with three working alternatives, and pinned by testSequenceShrinkInheritsCoreMergeSemantics so future refactors that try to "fix" this unilaterally fail the test and force the read-side conversation.

Tests

DomainConfigOverrideEditableTest (kernel, 5 tests / 22 assertions):

• testSetDataPreservesExistingOverrideAndAddsNewDiff — the BlockListBuilder::submitForm regression scenario.
• testSetDataDropsKeysThatNoLongerDifferFromBase — the #3547172 contract.
• testSequenceShrinkInheritsCoreMergeSemantics — pins both storage and runtime read to core's merge semantics.
• testSetPerKeyFlowProducesSparseOverride — non-regression for ConfigFormBase per-key flow.
• testSchemaDriftDoesNotProduceSpuriousDiff — empirically verified to fail when castThroughSchema() is disabled on $base_data.

Documentation

docs/domain_config/index.md gains Override write semantics (the diff-against-base contract) and Known limitation: sequence shrinks (with workarounds).

Deprecations (cleanup in domain:4.0.0)

• DomainConfigOverrideEditable::__construct(... ?array $base_data = NULL) — passing NULL triggers E_USER_DEPRECATED. The default goes away and the parameter becomes required in 4.0.0.
• DomainConfigOverrideEditable::updateExistingKeysInNestedArray() — removed in 4.0.0.

Out of scope (deferred)

The original scope of this issue (exposing the "Enable domain configuration" toggle on EntityForm-based config-entity edit forms — block, view modes, search pages, …) has been deferred to the domain_config_entity_ui submodule in domain_extras: #3588091. That submodule sits behind explicit per-entity-type opt-in via its own SettingsForm; the present MR ships the write-side correctness groundwork that any future EntityForm flow needs, with no UI changes and no opt-in surface in domain itself.