Issue #3618151: Document and cover the override view maintained by setOverride() (3.x deprecation)

The override object handed out by DomainConfigFactoryOverride::getOverrideEditable() carries two different things, and only one of them was documented anywhere.

initWithData() receives the base configuration merged with the domain's existing override, so $this->data holds what the domain resolves to. setModuleOverride($domain_data) receives the existing override row on its own, so $moduleOverrides answers "which keys does this domain override" — and that is what Config::hasOverrides() and Config::getOriginal() read. set() keeps that answer current as keys change. What actually reaches storage is unrelated: save() recomputes it as the diff against base.

Nothing covered any of it. Before this there was no test in the project calling hasOverrides() and none calling the method that maintains the view; the single getOriginal() call passes $apply_overrides = FALSE. That is why the regression in #3587744, which stopped the method from affecting stored configuration, reached 3.1.0-alpha1 with nothing failing.

Comments. Three described code that no longer exists:

• the pre-merge in getOverrideEditable() was justified by save() copying cast values back onto $moduleOverrides, a path removed by #3587744. The pre-merge is still needed, but because save() diffs against base, so a key missing from $data reads as "back to base" and drops out;
• the comment above the diff in save() recounted how moduleOverrides used to be accumulated and which case the old fallback missed;
• the test class docblock carried the same narrative.

All three now describe the current design.

Coverage. Four kernel tests: a freshly loaded override reports its stored keys, a key set afterwards joins them, a domain with no override reports none, and — the one that keeps the two concepts apart — a key can be reported as overridden on the object and still be absent from storage, because its value equals the base. Each was checked to fail for its own reason: dropping the factory's seeding fails the first, dropping the recording in set() fails the other two.

Deprecation. 3.x keeps setOverride() public and working, delegating to the new protected setModuleOverrideValue(), and triggers a deprecation pointing at set(). Removal and the rename land on 4.x in !436 (merged), since DomainConfigOverrideEditable is not @internal and instances reach callers through DomainConfigFactoryOverrideInterface.

Two extra tests cover it: the deprecated method still records the key and reports exactly one deprecation, and an ordinary set() reports none. Both use a local error handler rather than a PHPUnit helper, so they behave the same on every core and PHPUnit version this branch supports, including the previous major job.

Verified on Drupal 11.4.4: 12 kernel tests in the class. The deprecation test was checked to fail when the @trigger_error() is removed.