[1.x & 2.x] Discussion Metadata Stale after GDPR Erasure Request processed in deletion mode

### Current Behavior

When GDPR Deleting a user, posts are bulk deleted like this:

https://github.com/flarum/framework/blob/f49072ab828fa19e92460b9ffd707d41ca9aaa04/extensions/gdpr/src/Data/Posts.php#L54-L57

Bulk deletion like this skips over the events needed to keep the discussions in sync and retain data integrity

### Steps to Reproduce

1. Create a new test user
2. Start a few discussions, reply to some other discussions
3. Request GDPR Erasure as that testing user
4. Confirm the erasure request by that testing user
5. Process the erasure request as an admin

### Expected Behavior

Flarum Events should be dispatched (`dispatchEventsFor()`) which in turn would get listened to by the `DiscussionMetadataUpdater`.

### Screenshots

_No response_

### Environment

- Flarum version: 1.8.17
- Website URL: n.a.
- Webserver: n.a.
- Hosting environment: n.a.
- PHP version: 8.3.32
- Database 10.11.15 MariaDB
- Browser: n.a.

### Output of `php flarum info`

_No response_

### Possible Solution

_No response_

### Additional Context

I didn't test this locally against the 2.x version, however the implementation is the same there. Changing this behaviour is a technically a breaking change and ideally is done just for the 2.x branch, before 2.0.0 stable is released.

Start in extensions/gdpr/src/Data/Posts.php at the bulk deletion code around lines 54-57, then trace dispatchEventsFor() and the DiscussionMetadataUpdater listener. Reproduce the GDPR erasure flow with a test user who starts and replies to discussions, and verify that discussion metadata remains synchronized after processing the request.

Written by the indexing model from the issue text.