Warn when overriding a display option un-defaults grouped siblings

Depends on: #3621953, the fix that switched update_view_plugins to Views' own overrideOption() - this defect is specifically about that fix's own side effect, so it should land after that one.

Problem/Motivation

Also found by the same independent code review that found the expose partial-merge defect, this time checking the overrideOption() fix for edge cases. Views' own DisplayPluginBase::defaultableSections() groups several display options together as a single unit - for example style/row, or use_more/use_more_always/use_more_text - and overrideOption() un-defaults the whole group whenever any one member is set, not just the option actually requested.

Setting just one grouped option on a non-default display silently copies each sibling's currently inherited value into that display too, and permanently severs their inheritance from the default display from that point on - with nothing in the tool's output telling the caller this happened. A later change to a sibling option on the default display will no longer propagate to that display, and there's no way to know that without already knowing about this in Views' internal.

Steps to reproduce

1. Create a page display that is still inheriting use_more, use_more_always, and use_more_text from the default display.
2. Call ai_agents_views:update_view_plugins to set only use_more on that page display, e.g. true.
3. Inspect the page display's saved display_options: use_more_always and use_more_text are now present too, both un-defaulted, at whatever values the default display currently had.

Expected (or at least, something the caller is told): either only use_more changes, or the caller is warned that its siblings were affected too.

Actual (before this fix): all three options are silently frozen on the page display, with the tool's success message giving no indication anything beyond the one requested option changed.

Root cause

This is correct Views UI semantics, not a logic error - DisplayPluginBase::setOverride() (called by overrideOption()) is documented to operate on the whole defaultable section a given option belongs to, and the Views UI form itself edits and submits these grouped options together for exactly this reason. The gap is purely that the tool's own success message says nothing about it, so an agent (or a person reading the tool's output) has no way to know a request to change one option quietly affected others too.

Proposed resolution

Compute the affected sibling options via defaultableSections() before calling overrideOption(), and append a note to the tool's own success message naming them, whenever this occurs on a non-default display (grouping has no functional effect on the default display itself, so no note is needed there):

$display_handler = $view_executable->displayHandlers->get($display_id);
// Some options are grouped (e.g. style+row) - overrideOption() below
// un-defaults the whole group. Work out the affected siblings first so
// we can warn about it below.
$defaultable_sections = $display_handler->defaultableSections($display_option);
$grouped_siblings = array_diff($defaultable_sections ? $defaultable_sections : [], [$display_option]);
$display_handler->overrideOption($display_option, $config);
...
if ($grouped_siblings && $display_id !== 'default') {
  $this->list .= "\nNote: '$display_option' is grouped with " . implode(', ', $grouped_siblings) . " on '$display_id' - setting it also stopped " . implode(', ', $grouped_siblings) . " from inheriting further changes made on the default display, freezing them at their current values. Update those explicitly on '$display_id' too if they also need to change.";
}

Remaining tasks

• File this issue on drupal.org, noting the dependency above.
• Open an MR with the fix above, based on the overrideOption() fix branch.

Test coverage added locally

Two new regression tests in tests/src/Kernel/Plugin/AiFunctionCall/UpdateViewPluginsTest.php: testGroupedOptionOverrideWarnsAboutSiblings() sets use_more on a page display and confirms both that the tool's output names the frozen siblings and that they were genuinely copied in and un-defaulted, not just mentioned in the message; testUngroupedOptionOverrideHasNoSiblingWarning() confirms an option with no grouped siblings (e.g. title) produces no false-positive note.

Full suite with this fix applied (isolated on its own branch, based on the overrideOption() fix branch): 18/18 kernel tests passing (212 assertions) across UpdateViewPluginsTest and the two Integration tests from the base branch, no failures.

API changes

None. Tool result messages gain additional, purely additive text in the affected case - no new context parameters, no signature changes, no config schema changes.