Add parent entity columns to patternkit_block_validity for cleanup and orphan detection

Problem/Motivation

The patternkit_block_validity table (introduced in #3589846: Add validity stamp infrastructure and save-time validation enforcement for PatternkitBlock entities) stores one validity stamp row per patternkit block translation, keyed to (block_entity_id, langcode). No column links a row back to the parent entity (typically a node) whose Layout Builder layout contains the block.

Two problems follow from this gap.

Cleanup operations require a layout storage walk

Follow-on features that delete stamp rows on parent entity lifecycle events (unpublish, translation delete, block removal from a layout) must reconstruct Layout Builder section storage to discover which block entity IDs belong to the affected entity. With parent entity columns, this becomes a direct indexed query on layout_entity_type and layout_entity_id. Without them, each cleanup operation is proportional to the number of sections and blocks across all layouts for the entity.

The remediation dashboard cannot distinguish unresolved rows from orphaned rows

Cron-based stamp revalidation writes rows without knowing the parent entity context. A future backfill can reverse-query section storage to populate those columns. Without a resolution flag, two distinct states both have NULL layout entity columns, with no way to tell them apart:

• Cron stamped the block. The parent entity has not yet been looked up.
• A resolution check ran and found no layout referencing this block (confirmed orphan).

Drupal core's inline_block_usage table follows the same pattern for the same reason.

Proposed resolution

Add three columns to patternkit_block_validity:

• layout_entity_type (varchar, nullable): entity type of the layout host, e.g. node. NULL for cron-only stamps.
• layout_entity_id (int unsigned, nullable): entity ID of the layout host. NULL for cron-only stamps.
• parent_resolved (tinyint NOT NULL DEFAULT 0): 0 means the parent has not been resolved. 1 means either a known placement was confirmed by the save path, or a resolution check found no parent.

The Layout Builder entity save path always has the parent entity available and populates all three columns. The cron revalidation path writes NULL for the entity columns, leaving parent_resolved at 0. Cron re-stamps omit all three fields from the merge UPDATE clause so they do not overwrite save-path values already in the row.

With these columns, a future dashboard can categorize all stamp rows into three states:

This issue depends on #3589846: Add validity stamp infrastructure and save-time validation enforcement for PatternkitBlock entities for the patternkit_block_validity table and ValidityStampWriter service.

Remaining tasks

• Review and test the merge request.

User interface changes

None.

Introduced terminology

None.

API changes

ValidityStampWriterInterface::writeStamp() gains three new optional parameters, all defaulting to NULL: $layoutEntityType, $layoutEntityId, and $parentResolved. Existing callers are unaffected.

Data model changes

Three columns are added to patternkit_block_validity:

• layout_entity_type (varchar 128, nullable)
• layout_entity_id (int unsigned, nullable)
• parent_resolved (tinyint NOT NULL DEFAULT 0)

A composite index on (layout_entity_type, layout_entity_id) supports the cleanup queries described above.

Two update hooks handle existing installations. patternkit_update_10312 adds the layout entity columns and index. patternkit_update_10313 adds parent_resolved.

Release notes snippet

patternkit_block_validity now records the layout host entity type, entity ID, and a resolution flag alongside each stamp row. These columns enable direct stamp cleanup queries by parent entity, without walking Layout Builder section storage, and support a future remediation dashboard that distinguishes blocks in known placements from cron-only stamps pending resolution. No data migration is required.