Revert Render-Time Validation for Smooth Upgrade Path from 9.1.2 with Existing Invalid Content

Problem/Motivation

Unconditional render-time JSON Schema validation in PatternFieldProcessorPluginManager::processSchemaValues must be removed. It regresses behavior relative to Patternkit 9.1.2: sites that upgrade can see visitor-visible "This content is unavailable." for blocks whose stored configuration fails JSON Schema checks (for example required or minLength) even though 9.1.2 still rendered those blocks. Separately, token values in format-constrained fields may produce WARNING-level log noise on render in some configurations, but that scenario is harder to reproduce when server-side preprocessing already bypasses format validation for tokens.

This behavior was introduced on the 9.1.x branch after the 9.1.2 release via #3563760: Add Pattern Content Validation During Rendering (merge request and commit history on that issue). The intent—extra safeguards during rendering—is sound, but the current implementation runs two validation passes on every render without configuration or stamp-based gating, which is incompatible with real content that 9.1.2 already served and with gradual upgrade expectations.

Relationship to #3563760: This issue documents why that render-path change needs to be reverted for the next stable release line, while keeping the validation helper infrastructure (assertValidPatternContent, PatternValidationHelper, and associated tests) so a follow-up, stamp-aware render policy can use it without reintroducing the same upgrade break.

Steps to reproduce

The patternkit_test module included in this MR provides a dedicated Render validation test component that covers each constraint class the regression affects. This is the recommended reproduction path, as it requires no schema modification.

Setup (required once):

1. Apply MR !187 (or check out the branch 3583333-revert-render-time-validation and temporarily revert it to reproduce the regression).
2. Add the following to settings.php so Drupal's extension discovery scans tests/modules/:
   

   $settings['extension_discovery_scan_tests'] = TRUE;

3. Enable the test module: drush en patternkit_test

Reproducing the WARNING regression (Email, Hostname, Date/Time fields):

1. Place a Render validation test block in Layout Builder.
2. Enter a Drupal token in the Email field (e.g. [user:mail]) and save.
3. Clear caches (drush cr) to force a cache-miss render and load the page.
4. With the regression present: WARNING-level log entries appear in /admin/reports/dblog for that block's pattern ID on every cache-miss render.
5. With this MR applied: No WARNING is logged. The block renders normally.

Reproducing the "content unavailable" regression (type mismatch):

1. Use drush pkset to inject a non-string value (e.g. integer 42) into the Label field of a Render validation test block instance, bypassing the editor form.
2. Clear caches and load the page.
3. With the regression present: "This content is unavailable." renders instead of the block output.
4. With this MR applied: The block renders without error.

Note: Reproducing the 9.1.2 baseline on Drupal 11 using the Patternkit 9.1.2 tag may require applying the Drupal 11 compatibility fix from commit 01abf92 first. Without it, Drush and full bootstrap can terminate with a fatal error: LayoutHelper and LayoutEntityHelperTrait define the same property ($sectionStorageManager) with incompatible definitions.

Proposed resolution

Revert the two assertValidPatternContent calls from the render path inside processSchemaValues—specifically, remove the pre-traverseSchema call (soft validation / logging) and the post-traverseSchema call (strict validation / exception). Field processor traversal and existing SchemaException handling remain unchanged.

In scope

• Restore 9.1.2-equivalent render-time behavior for pattern block value processing (no JSON Schema value validation inside processSchemaValues on each render).
• Retain assertValidPatternContent, PatternValidationHelper, and unit coverage for them for use by future work.
• Expand automated tests to verify the 9.1.2-parity contract across all relevant constraint classes: unit and kernel tests for processSchemaValues now use data providers covering a plain string type, all four swaggest-validated format keywords (uri, email, hostname, date-time), and a regex pattern constraint. A dedicated render_validation_test component in patternkit_test provides one field per constraint type for both automated and manual verification.

Out of scope

• Implementing replacement stamp-aware or tiered render-time validation (planned as a separate follow-up issue and release target).
• Save-time enforcement toggles, token-format bypass at save time, or stamp table work—those are parallel tracks and must not be conflated with this revert.

Path forward after this revert: Reintroduce render-time validation only behind an explicit policy (for example validity stamps and schema fingerprinting) so upgrades from 9.1.2 do not suddenly fail or flood logs for previously accepted content. That follow-up should reference this issue and #3563760 for historical context.

Remaining tasks

• Peer review and RTBC. MR !187 is open against 9.1.x; CI is green on PHP 8.1 and PHP 8.3.
• After merge, add a short comment on #3563760 linking this issue and the merge request, summarizing the regression and pointing readers at the planned stamp-aware follow-up (separate issue).

User interface changes

None. Restores prior rendering behavior for affected blocks; administrators may see fewer log warnings and fewer "content unavailable" fallbacks after upgrade.

Introduced terminology

None.

API changes

None. processSchemaValues stops performing render-time content validation; callers and signatures are unchanged. Validation helpers remain available for other code paths and future policy work.

Data model changes

None.

Release notes snippet

Removed unconditional JSON Schema validation from the pattern render path (PatternFieldProcessorPluginManager::processSchemaValues) to match Patternkit 9.1.2 behavior and avoid upgrade-time log noise and unintended "content unavailable" fallbacks. See related issue #3563760 for the original render-time validation change and this issue for the revert rationale.