Plan: Pattern presets [#3621315]

Problem/Motivation

A preset is a stamp, not a symbol. Dropping one copies its sources into the current display and the link is gone. The Libraries panel gives components, blocks and presets the same affordance, a labelled row you drag onto the canvas, and nothing on screen says that only one of the three does not propagate.

Users assume the opposite and find out after editing twelve copies.

Two consequences drive this meta:

#3617547: Make pattern presets buildable makes a preset editable in the builder. That is the strongest possible signal that a preset is live. The feature and the misunderstanding ship together.
The distribution half of the feature, a preset shipped by a theme, an agency or a recipe, does not work yet. A Bootstrap preset is offered on a DaisyUI site and renders wrong.

Proposed resolution

Name the propagation, never the storage. "Config entity" and "SDC" are true and useless. "Dropping this makes a copy" is the whole product difference.

The contract, in the product's words:

Editing a preset changes what gets dropped from now on. Displays that already use it do not change.

Vocabulary settles as one noun, preset, in every user-facing string. pattern_preset stays as the machine name and config prefix.

A preset stores no reference to the display it came from, and no profile. Anything site-specific on a preset breaks the distribution half.

Remaining tasks

Before RC1:

#3617547: Make pattern presets buildable Make pattern presets buildable. Title "Preset: label", a post-publish message stating the contract, contexts from a sample entity, docs.
[Child issue] Offer a preset only where it can render: theme dependencies and existing components.
[Child issue] Say "preset" in every user-facing string.
[Child issue] Inserting a preset makes one undo step per island setting.
[Child issue] Paste and preset insert end in a server error when the target is full or gone.

After RC1:

[Child issue] Reading the group of a pattern preset saves the preset.
[Child issue] Replace the "Save as preset" prompt with a real dialog: label, group, description, contract sentence.
One always-visible line under each Libraries tab search box, and the delete-form reassurance.
Update an existing preset from a new canvas selection. A shortcut once presets have their own builder.

#3546964: Better context management in presets closes as a duplicate once #3617547: Make pattern presets buildable lands.

User interface changes

Preset builder: title naming the preset, Publish kept, a post-publish message: "Published. New drops use this version. Displays that already use it do not change." Restore kept, it discards the draft. Revert does not apply.
Admin collection row operations: Edit details and Edit layout. Adding a preset opens the builder.
Libraries tabs gain one line of text each. Presets reads: "Ready-made arrangements. Dropping one makes a copy you can edit here."
Delete form states: "Deleting a preset does not affect displays that already use it."
Empty state names the gesture: "Right-click any element on the canvas, then Save as preset."

Out of scope, in the UI and in the data model: no chain or link icon on a preset row, no badge on a dropped node saying where it came from, no usage count, no "where used" tab, no warning on delete. A dropped preset leaves no reference, so any of those is a promise the data model cannot keep. A persistent banner in the preset builder is deferred: it needs a new toolbar API, and the title plus the post-publish message come first.

API changes

Only the pattern_preset buildable plugin from #3617547: Make pattern presets buildable, in display_builder_ui. No new attribute key, no new interface method on DisplayBuildableInterface.