[Task]: Correctly Identify Affected User in Admin Event Payloads

### Analysis
For admin events, the payload's `userId` field is misleadingly populated with the ID of the administrator who performed the action, not the user who was affected. The affected user's ID is only available by parsing the `resourcePath` string (e.g., `users/some-user-id`).

### Necessity
**Critical.** This is a bug fix. The current behavior is incorrect and makes the payload difficult to consume reliably. A consumer of a `USER-DELETE` event expects the `userId` to refer to the user who was deleted.

### Backward Compatibility & Safety
The proposed solution is **fully backward compatible**.
- Existing consumers will not see a change in the fields they currently use.
- New consumers, or existing ones that are updated, can use the new `affectedUserId` field to get the correct information. This avoids any breaking changes.

### Proposed changes
- **Phase 1: Expand Data Model (Breaking Change)**
- Remove the `userId` field.
- Add a nullable `adminId` field.
- Add a nullable `affectedUserId` field.

- **Phase 2: Implement Core Logic**
- Create a `parseAffectedUserId` function to extract the ID from `resourcePath`.
- Update `onEvent` for **admin events** to populate `adminId` and `affectedUserId`.
- Update `onEvent` for **user events** to populate `affectedUserId` (leaving `adminId` null).
- Update the `send` method to accept and assign the new IDs to the payload.

- **Phase 3: Announce Breaking Change**
- Update documentation and release notes.
- Clearly state that `userId` has been removed from admin event payloads and replaced with `adminId` and `affectedUserId`.
- Instruct consumers that they must update their code to use the new fields.

### Keycloak Version Compatibility
The structure of `AdminEvent` and the `resourcePath` format is stable across Keycloak versions. This change is expected to be fully compatible.