[EPIC]: Implement Transactional User Creation via UserStorageProvider Decorator

### Analysis
Keycloak's event listener SPI is intentionally designed to be post-transaction. Events are fired only after a database transaction is successfully committed. This prevents event listeners from interfering with core Keycloak operations, but it makes it impossible to roll back a transaction due to a listener's failure.

### Necessity
**High (for specific use cases).** For systems requiring strong data consistency with Keycloak, this is a critical feature. For example, if creating a user in an external billing system fails, the user should not be created in Keycloak either. However, for many users, the current "fire-and-forget" behavior is sufficient and safer.

### Proposed changes
- **Phase 1: Create a New `TransactionalUserStorageProvider`**
- This provider will act as a **decorator**, wrapping Keycloak's default user storage provider.
- It will override the `addUser` method to intercept user creation.
- Inside `addUser`, it will first create the user, then send the webhook.
If the webhook fails, the Keycloak transaction will be forced to **roll back**.

- **Phase 2: Add Configuration**
- Add a constant for the `WEBHOOK_ENABLE_TRANSACTIONAL_BEHAVIOR` environment variable to act as a feature flag.

- **Phase 3: Register the New Provider**
- Modify the `META-INF/services/org.keycloak.storage.UserStorageProviderFactory` file.
- Add the name of the new provider's factory to this file so Keycloak can discover and load it.

### Backward Compatibility & Safety
Any implementation of this **must be disabled by default** and enabled with an explicit environment variable, e.g., `WEBHOOK_ENABLE_TRANSACTIONAL_BEHAVIOR=true`. Enabling this would fundamentally change the provider's behavior and could risk impacting Keycloak's stability if not implemented perfectly.