Restore static S3 Vanity URL support for dotCMS 2 compatibility

[riccardoruocco]

Problem

During our migration from dotCMS 2 to dotCMS Evergreen, we found that static publishing no longer materializes Vanity URLs as static aliases.

In dotCMS 2, this behavior appears to have been supported, so the current Evergreen behavior breaks backward compatibility for sites that rely on Vanity URLs in static environments.

Goal

Restore opt-in support for Vanity URLs on static S3 publishing so dotCMS can preserve backward compatibility for customers migrating from dotCMS 2 to dotCMS Evergreen.

Proposed Approach

• Introduce a feature flag to enable or disable the behavior.
• Track materialized vanity aliases in an operational table.
• Use that table to keep publish, republish, unpublish, and delete in sync with the S3 bucket.
• Support restoring an existing live resource when a Vanity URL is removed and it was shadowing a real dotCMS resource.

Acceptance Criteria

• When the flag is disabled, static publishing behavior is unchanged.
• When the flag is enabled, publishing a Vanity URL creates the expected S3 clone.
• Republish updates existing materialized aliases.
• Unpublish and delete remove the clone and the mapping row.
• If a vanity path was shadowing a live resource, removing the vanity restores the original resource.

Related PR

• Add S3 static publishing support for vanity URLs #35643