Changes to shared paragraphs_library items do not trigger host entity revision or update timestamps

Problem/Motivation

When using the Paragraphs module with the paragraphs_library submodule enabled, shared library paragraphs can be referenced by multiple host entities (e.g. nodes, blocks, etc.).

If a shared library paragraph is updated directly (via the admin UI or programmatically), host entities that reference it are not updated. Specifically:

• No new revision is created on the referencing host entities.
• The changed timestamp of the host entities does not update.
• The sitemap and other systems that rely on the changed timestamp (e.g. simple_sitemap, metatag, JSON:API consumers) do not reflect the update.

This leads to stale or incorrect metadata and indexing for referencing content. The end-user sees the updated paragraph content, but automated systems believe the page hasn't changed.

This behavior is confusing and breaks expectations for revision-aware and time-sensitive tools like sitemaps, feeds, or decoupled apps.

I'm not sure if this is a bug, a feature request, or intentional functionality, so please adjust as you see fit.

Steps to reproduce

1. Enable the Paragraphs module and paragraphs_library submodule.
2. Create a paragraph and save it to the library.
3. Create a node with a Paragraph field that references this library item.
4. Save the node.
5. Update the paragraph in the library directly.
6. Do not resave the referencing node.
7. Visit the node and confirm the updated paragraph content is shown.
8. Check the node’s changed timestamp or sitemap — it has not changed.

Proposed resolution

The core issue is that entity reference revisions don't propagate changes up to host entities.

Potential solutions include:

✅ Option 1: Programmatically trigger host entity revisions when shared paragraph is updated

1. Hook into hook_entity_update() for paragraph entities of type library_item.
2. Find referencing entities.
3. Create a new revision and update changed timestamp on each host.

We will need to address the behavior around drafts and content in other revision states, as the latest revision might not be the active revision.

✅ Option 2: Update changed timestamp without new revision

I'm not sure what unintended side-effects this might have. Working around standard entity operations always worries me.

$host->set('changed', \Drupal::time()->getRequestTime());
$host->save();

Remaining tasks

1. Get maintainer feedback on preferred solution direction.
2. Confirm if this should be addressed in paragraphs_library or in a helper module. This functionality could be toggled on/off with configuration if it is kept in the paragraphs_library module.
3. Create a patch or module implementing one of the proposed solutions.
4. Add test coverage (if in core module).
5. Document behavior in paragraphs_library README.

User interface changes

Changes would be backend-only.

API changes

None in initial implementation. Potential for a service to expose referenced entity update triggers.

Data model changes

None. Reuses existing revision and timestamp systems.