TrashStorageTrait uses entity-type isRevisionable() instead of per-entity isNewRevision() when creating trash revisions

Problem/Motivation

In TrashStorageTrait::delete() and TrashStorageTrait::restoreFromTrash(), the $revisionable flag is initialised once, before the entity loop, using $this->getEntityType()->isRevisionable():

$field_name = 'deleted';
$revisionable = $this->getEntityType()->isRevisionable();

foreach ($to_trash as $entity) {
    // Always create a new revision if the entity type is revisionable.
    if ($revisionable) {
        $entity->setNewRevision(TRUE);
        ...
    }
}

isRevisionable() is a type-level capability flag — it answers "does this entity type support revisions?" not "should this specific entity create a new revision right now?" As a result, the trait unconditionally calls $entity->setNewRevision(TRUE) for every entity of a revisionable type, ignoring the per-entity revision state entirely.

This is particularly disruptive for entity types such as Paragraph, where revisions are created and owned by the host entity (e.g. a Node). When a paragraph is soft-deleted or restored through Trash, the module creates an independent paragraph revision that is not anchored to any node revision. This produces orphaned revision rows in the database and can break the integrity of the host entity's revision history.

The correct check is $entity->isNewRevision(), which reflects the actual per-entity revision intent at the time of the operation — whether that intent was set explicitly by the caller or by a bundle-level default.

An example: The media entity type is revisionable (it has revision_table: media_revision and revision: vid in its entity keys). Individual media types, however, can set new_revision: false in their bundle config — the core Image media type ships with this as its default. Trashing or restoring an Image media entity triggers the bug: Trash forces a new revision entry into media_revision for a bundle that was never configured to use them.

The correct check is $entity->isNewRevision(), which reflects the actual per-entity revision intent at the time of the operation. For entities loaded from storage whose bundle has new_revision: false, isNewRevision() returns FALSE and setNewRevision(TRUE) is never called.

Steps to reproduce

1. Enable the Trash module on a Drupal 11 site with Paragraphs (or any other revisionable entity type whose revisions are managed externally, e.g. by a host entity).
2. Enable Trash for that entity type (e.g. paragraph).
3. Soft-delete a Paragraph entity — either programmatically via $entity->delete() or through the UI.
4. Inspect the paragraph_revision table (or equivalent revision table). An extra revision row has been created by Trash independently of any host Node revision.
5. Restore the entity from Trash ($storage->restoreFromTrash([$entity])).
6. Observe another orphaned revision row created on restore, again unrelated to any Node operation.

Proposed resolution

Override $revisionable per entity inside the foreach loop using $entity->isNewRevision(). This delegates the revision decision to the entity itself — consistent with how Drupal core handles revision creation throughout the entity save pipeline.