Recreating a trashed redirect inside a workspace fails with a duplicate hash database error

Problem/Motivation

Editing a node's URL alias back and forth between two values inside a workspace can crash with a raw database error:

SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '...' for key 'redirect.hash'

Steps to reproduce

1. Create a workspace and switch to it.
2. Create a page with alias /alpha.
3. Change the alias to /beta — Redirect auto-creates a redirect from /alpha.
4. Change the alias back to /alpha — the /alpha redirect gets trashed, and a new redirect from /beta is auto-created.
5. Change the alias to /beta again — trashing the /beta redirect and recreating the /alpha one throws the error above.

Root cause: once the Redirect entity is revisionable and workspace-supported (see #3313540: Convert the Redirect entity type to revisionable), a new redirect's first revision is always inserted as the live default revision, even inside a workspace. But trashing an existing redirect inside a workspace only creates a pending, non-default revision — the live/default revision, which is what the hash unique key actually constrains, is never touched. So the redirect's original hash stays "live" in the database even after it's trashed. When the alias flips back and a new redirect needs to reuse that same source path, the insert collides with that untouched original hash.

Proposed resolution

Before creating a new redirect for a given source, check whether a redirect with that exact source was already trashed, and if so, restore it instead of creating a new entity. Restoring reuses the same database row rather than competing with it for the same hash, so the collision never happens, regardless of whether the trashed redirect was created inside the current workspace or predates it.