[2.x] fix: TypeError in Revised event when post content is NULL

[imorland]

Summary

Fixes #4606. `CommentPost::revise()` raises a `Flarum\Post\Event\Revised` whose constructor types `$oldContent` as non-nullable `string`. But the `posts.content` column is nullable — legacy/imported posts and extension-created posts can have `NULL` content. Editing such a post throws a `TypeError` on every save and pollutes the log.

Root cause

```php
// CommentPost::revise()
$oldContent = $this->content; // ← can be null
$this->raise(new Revised($this, $actor, $oldContent));
```

```php
// Revised::__construct
public string $oldContent // ← rejects null
```

```
TypeError: Flarum\Post\Event\Revised::__construct(): Argument #3 ($oldContent) must be of type string, null given
```

Fix

Coalesce at the call site:

```php
$oldContent = $this->content ?? '';
```

Chosen over widening `Revised::$oldContent` to `?string` because:

1. RC-friendly — no public-API change. Any extension that does `strlen($event->oldContent)` or similar without a null check keeps working.
2. Semantic loss is negligible — distinguishing "was empty string" from "was null" is meaningful in principle, but no listener in core or any bundled extension actually uses that distinction; `grep oldContent framework/ extensions/` finds zero consumers.
3. Future-friendly — if a real need emerges to widen the type later, that's an additive change. Going `?string` now would commit us to that signature.

Tests

New `framework/core/tests/integration/api/posts/UpdateTest.php` (the file didn't exist — there was no integration test for post updates):

1. `revising_a_post_with_null_content_does_not_throw` — calls `revise()` on a post whose `content` is null and asserts no exception, content updated correctly.
2. `revising_a_post_with_null_content_raises_revised_event` — asserts the event is still raised and `oldContent` is `''` (not skipped).

Both tests fail against pre-fix code with the exact `TypeError` from the bug report; both pass after the fix.