Fix attachment displays saving with no 'displays' value

Problem/Motivation

An Attachment display is not usable until its displays option names the display(s) it attaches to - creating the display alone leaves it attached to nothing. This saves without any tool error and passes View::validate() cleanly, since an attachment display with no target is not invalid Views config, just functionally useless.

Live-tested against the shipped agent with an explicit, unambiguous request ("add an attachment display that attaches before the page_1 display"): the agent created the attachment display and correctly set attachment_position: before, but never set displays at all. The resulting display was confirmed genuinely non-functional: ViewExecutable::attachDisplays() found nothing to attach to, and the target page never rendered the attachment alongside it.

Steps to reproduce

1. Create an attachment display on a View with at least one other real display (e.g. page_1) with ai_agents_views:create_view_display.
2. Ask the tool what to set the attachment's displays option to, by calling ai_agents_views:update_view_plugins with display_id and display_option: "displays" but no config.

Expected: the tool's "available config values" response lists the View's real other display IDs (e.g. page_1), so the agent knows what to set.

Actual (before this fix): both the "existing" and "available" values come back as an empty array ([]) - no hint that real display IDs are valid, or that the option expects a keyed map of display ID to display ID at all.

Root cause

ViewsAgentHelper::getViewDisplayOptionsConfigSuggestions() is a match() keyed by display-option name, with hand-picked example values for options like title, pager, style, row, access, exposed_form, and relationships - but had no case for 'displays', so it fell through to the default, empty array. Since displays is also never set on a freshly-created attachment display, getViewDisplayOptionsConfig()'s own "existing" value is empty too - so the tool told the agent both existing and available values were [], with nothing to go on.

This is the same class of gap as the earlier use_admin_theme discoverability defect, just on the "what value goes here" side rather than the "does this option exist at all" side.

Proposed resolution

Add a 'displays' case that returns the View's other real display IDs, keyed by themselves - exactly the shape the option expects:

'displays' => $this->getOtherDisplayIdsSuggestion($display),
...

protected function getOtherDisplayIdsSuggestion(DisplayPluginInterface $display): array {
  $current_display_id = $display->display['id'];
  $other_display_ids = array_diff(array_keys($display->view->storage->get('display')), [$current_display_id]);
  return array_combine($other_display_ids, $other_display_ids);
}

Also documents the full workflow in the system prompt: create the attachment display, set displays to the exact {"page_1":"page_1"} shape (confirming the real display ID first, since a view can have several page displays), set attachment_position, and add the attachment's own fields/filters/sorts like any other display.

Remaining tasks

• File this issue on drupal.org.
• Open an MR with the fix above.

Test coverage added locally

Regression test testDisplaysOptionSuggestsOtherDisplayIds() in tests/src/Kernel/Plugin/AiFunctionCall/UpdateViewPluginsTest.php confirms the tool now suggests the View's real other display ID (page_1) when asked what to set displays to on a fresh attachment display, then sets it and confirms the correct, real value round-trips through the saved config.

Full suite with this fix applied (isolated on its own branch): 15/15 kernel tests passing (126 assertions) in UpdateViewPluginsTest, no failures.

API changes

None to the tool's own context definitions. Adds one new protected method (getOtherDisplayIdsSuggestion()) to ViewsAgentHelper.