Document how to build a valid RSS feed display

Problem/Motivation

A feed display added through ai_agents_views:create_view_display is not usable until its row style is fully configured - creating the display alone leaves it invalid. Before this change, no prompt guidance existed for this workflow at all, so the shipped Views Agent had nothing to go on beyond guessing.

Worse, the generic rss_fields row style - the more "obvious" choice, since it maps individual fields - produces config that passes View::validate() cleanly while still not being valid RSS, unless every mapped field is exactly the right shape: a plain-text title (not one rendered as an HTML link), a raw usable URL or path for the link (not HTML-formatted), and an RFC 2822-formatted date. validate() cannot tell a correctly configured feed from a plausible-looking broken one - only reading the actual rendered output can.

Steps to reproduce

This is a prompt/documentation gap, not a deterministic code defect, but it reproduces reliably against a real LLM:

1. Create a feed display on a node-based View with ai_agents_views:create_view_display.
2. Ask the agent (with no other guidance) to configure it to produce a working RSS feed.
3. Read the actual rendered XML output of the feed display, not just its saved config or validate() result.

Observed (before this change), in order:

1. With no workflow guidance at all, a feed display was created with every RSS field mapping left empty - validate() at least caught this directly ("Row style plugin requires specifying which views fields to use for RSS item").
2. After adding guidance for the rss_fields row style's sub-keys, the agent produced config that satisfied validate(), but the rendered <title>/<link> contained escaped HTML markup (from a title/link field formatted as a link), and <pubDate> was a human-readable date, not RFC 2822 - not a valid feed despite validating cleanly.
3. After rewriting the guidance to recommend Drupal core's own working pattern - the dedicated node_rss row plugin, which needs no field mapping at all - and asking the agent to use "node_rss" by name, it instead saved type: 'entity:node': a plausible-sounding but entirely different, generic row plugin that renders raw teaser HTML with no RSS <item>/<link>/<guid> structure at all - an even more broken result than step 2, despite being told the correct plugin's exact name.

Root cause

Not a code defect - both node_rss and rss_fields (and, for that matter, entity:node) are individually valid Views row plugin configurations; ai_agents_views:update_view_plugins correctly saves whichever one it's asked to. The gap was entirely in the shipped system prompt: no workflow guidance existed for feed displays, the guidance that was added first recommended the more error-prone of the two options core itself doesn't use for this purpose, and even once corrected, the prompt didn't explicitly warn against the specific "node_rss" vs. "entity:node" name confusion that a live LLM actually made.

Reading Drupal core's own working RSS feed (core/modules/node/config/optional/views.view.frontpage.yml) confirmed it uses neither of the agent's first two attempts: a dedicated node_rss row plugin (core/modules/node/src/Plugin/views/row/Rss.php), rendering each node through its rss view mode, with no field-by-field mapping needed at all. rss_fields is the generic, more error-prone fallback Views ships for entity types with no dedicated <entity>_rss plugin - only node and comment have one in core.

Proposed resolution

Adds a "Common Workflow: Add A Feed Display" section to the system prompt that:

• Leads with the node_rss row type for node-based Views, giving the exact config shape verbatim ({"type":"node_rss","options":{"relationship":"none","view_mode":"rss"}}), and explicitly warns against substituting "entity:node" by name, describing exactly why that substitution produces an invalid feed.
• Keeps rss_fields only as a documented, carefully-caveated fallback for entity types with no dedicated row plugin, spelling out each of its five required field mappings and the specific formatting trap for each one (plain-text title, raw URL for the link, RFC 2822 date).
• Tells the agent to verify the display actually validates after configuring the row style, since a wrong-but-non-empty mapping saves with no tool error.

Remaining tasks

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

Test coverage added locally

New Integration test ConfigureFeedDisplayTest::testNodeRssRowStyleProducesValidFeed() builds a feed display through the real tool chain (create_view, create_view_display, update_view_plugins for both row and path) and reads the actual rendered RSS XML - the only way this class of problem is caught, since validate() alone cannot tell a correctly-configured feed from a plausible-looking broken one. It asserts a real <item> element, a plain-text <title>, a real usable <link> URL, and an RFC 2822-formatted <pubDate>.

Full suite with this change applied (isolated on its own branch): 1/1 kernel test passing (21 assertions), no failures.

API changes

None. This is a change to the shipped default configuration (a system prompt section) plus new test coverage, not to any plugin's API surface.