Restructure the Views Agent system prompt and remove list_sample_view

Problem/Motivation

The Views Agent's shipped system_prompt was terse and under-specified: it named a handful of tools and a short numbered workflow, but gave the LLM no concrete guidance on the shapes of the values each display_option/handler config expects (pager types, access plugins, style/row plugins, boolean filters, CSS class, "more" link, and so on). In practice, this meant the agent had to guess at JSON shapes for common Views settings, which is exactly the kind of thing a system prompt should remove the need to guess.

Separately, the agent's tool list still included ai_agents_views:list_sample_view, a tool that is redundant with the agent's other listing/inspection tools and added noise to both the prompt and the tool set without pulling its own weight.

Proposed resolution

Restructure system_prompt with explicit sections so the model has a concrete reference instead of having to infer config shapes:

• Safety Rules - the non-negotiable constraints (no deleting Views, no changing an existing View's base table, always confirm the machine name, always fetch current state before changing it, don't report success prematurely).
• Key Concepts - what a View and its displays are, and when to change the default display versus a specific page/block display.
• Handler Types - a single, de-duplicated reference for field/filter/sort/relationship/argument/header/footer/empty handlers.
• Option Value Formats - worked JSON examples for every display_option the agent is expected to set: pager (full/mini/none/fixed), access (permission/role/none), cache (tag-based/none), style and row (unformatted/table/grid/HTML list, fields vs. entity rendering), CSS class, "more" link and its target display, enable/disable, and the boolean-filter/bundle-filter/sort-order shapes. Each example was verified against the real update_view_plugins/create_view_handler tools before being written into the prompt, not assumed.
• Per-workflow sections (Creating a View, Creating a Display, Adding/Updating/Removing Handlers, Updating Display Plugins) plus worked Common Workflow examples (a content listing page, adding fields, exposed filters, a block display, pager/access/cache/style configuration, CSS class and "more" link) and a closing Best Practices section.

Also:

• Remove ai_agents_views:list_sample_view from the agent's tools, tool_settings, and tool_usage_limits - the plugin itself is untouched and still available for other uses, it is simply no longer part of this agent's tool set.
• Remove the stray uuid from the shipped config and the no-longer-applicable node module dependency.

Remaining tasks

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

Test coverage

ViewsAgentTest::testAgentTools in tests/src/Kernel/Integration/ViewsAgentTest.php is updated to match: the block that exercised ai_agents_views:list_sample_view as its own step is removed, and the following step is renumbered. ViewsAgentTest::testAgentToolsResolve() needed no change - it iterates $agent->get('tools') dynamically rather than asserting specific tool IDs, so it already covers whatever tool set the agent ships with.

Full kernel + integration suite for ai_agents_views passes with this change: 63/63 tests, 622 assertions, no failures (1 pre-existing unrelated skip).

API changes

None. This changes the shipped default configuration (a system prompt and a tool list), not any plugin's API surface.