Support Cloudinary notification webhooks to auto-resync public_id on rename/delete

Problem/Motivation

When an asset already referenced by a Drupal Media entity is renamed or moved to a different folder in the Cloudinary DAM, the referencing Cloudinary field's stored public_id goes stale.
Today the only way this gets noticed is when something tries to resolve that public_id again (e.g. on render) and the Admin API 404s, see the related bug report (#3613941, filed separately) for the uncaught-exception crash this caused, and its stopgap fix.
Nothing in the module currently reacts to the rename/delete actually happening.

Cloudinary already emits notification webhooks the moment a rename or delete happens in the DAM, including, for accounts on Fixed/legacy folder mode, the exact from_public_id => to_public_id mapping in the rename payload. That's enough information to correct the stored reference immediately and network-wide, without waiting for a page view to trigger a lazy re-resolve.

Proposed feature:

Add an optional webhook receiver to cloudinary_sdk (or a new submodule) that:

• Exposes a route Cloudinary's notification system can call.
• On a rename notification: updates any stored public_id matching from_public_id (scoped by resource_type and delivery_type to avoid cross-type collisions) to to_public_id.
• On a delete notification: exposes a hook/event other modules can subscribe to, so sites can flag or clean up references to the now-deleted asset without needing to define that behavior in core.
• Returns non-200 on failed verification or an unrecognized notification type, so Cloudinary's retry/backoff behavior works correctly.
• Is idempotent, replaying the same webhook delivery must be a safe no-op.

Scope note: this only covers Fixed/legacy folder mode's rename event (folder path embedded in public_id). Dynamic Folder Mode's move event (from_asset_folder/to_asset_folder) is a related but distinct case with different payload shape and is out of scope for this request, worth its own follow-up if there's interest.

Why this belongs in the module rather than a one-off custom build: any site using this module and Fixed folder mode has the same staleness problem the moment editors reorganize their DAM folders. A signature-verified webhook receiver is generic, reusable plumbing that doesn't depend on any site-specific data model, only the rename-update and a delete hook are truly generic; anything account-specific (e.g. how a site tracks/display broken references) can stay downstream via the delete hook.

Related issues: #3078828, #3171412, same underlying failure family (stale/malformed Cloudinary reference causing an uncaught exception) that this feature would help prevent from recurring, though those issues address the crash reactively rather than the staleness proactively.