The condition does not describe itself: empty tab on the block form, and a summary that ignores the negation

Problem/Motivation

A condition is supposed to describe how it is configured, in two different places, and this one fails at both.

On the block configuration form, the vertical tab for this condition shows no summary at all. Every condition Drupal ships shows one, either the list of what is selected or the words "Not restricted", so a tab that stays blank reads like something is broken. The cause is that core builds those summaries in JavaScript, in block.js, from a hardcoded list of selectors that only covers its own conditions. The list is not extensible, so a condition from a contributed module gets nothing unless it provides its own callback.

Separately, the summary() method, which is what presents the condition anywhere outside the block form, is wrong rather than missing. With the negation checked it says "The entity holds a search paragraph", the exact opposite of what the condition does. It never mentions the entity types and bundles, so two conditions restricted to completely different parts of the site describe themselves identically. And with no paragraph type selected it says "Any paragraph type", which reads as a deliberate match-everything when the condition is simply not restricting anything.

Proposed resolution

For the block form, add a small behaviour that registers a summary callback for this condition's tab. It is the same callback core uses for its own checkbox based conditions, which cannot be reused directly because the selector list in block.js is not extensible: it lists the labels that are checked, or "Not restricted" when none are. Keeping it identical to core's means the tab reads exactly like the ones next to it, and there is no summary logic duplicated between PHP and JavaScript.

Note that a custom behaviour is the only option here, not a shortcut. There is no render array property for a vertical tab summary: the text comes from a callback stored on the element with jQuery data, and core does this from JavaScript in fourteen different files, including node, path, menu_ui, filter, media and block itself.

For summary(), rewrite it to report what is actually configured. With no paragraph type selected it returns "Not restricted", the same wording the block form shows for an unconfigured condition, so the two agree instead of contradicting each other. Otherwise it returns one of four sentences chosen by whether a scope is configured and whether the condition is negated. Each case is a complete separate sentence rather than fragments joined together, which is how the core conditions are written and what translators need in order to reorder the parts for their language.

The two are fixed together because they are the same defect seen from two sides, and because the block form summary is the part a site builder actually sees.