fix(facebook): empty-message rejection + state consistency + no re-publish on terminal

[paulocastellano]

Production incident

A customer's Facebook Page post failed with 'The post is empty. Please enter a message to share.' (FB Graph API error code 197), then ended up with a contradictory DB row: `status=published` + `platform_post_id=set` + `error_message='The post is empty...'`.

DB evidence on the failed PostPlatform:
```json
{
"category": "unknown",
"platform_error_code": "197",
"failed_at": "2026-05-15T13:34:24+00:00",
"content_length": 0,
"media_count": 2
}
```

Investigation surfaced three independent bugs that conspired to produce the customer experience.

Bug A — `FacebookPublisher` sends `message: null` to Graph API

When the user has media without text, `$content` is null. The 4 publish paths (`publishSingleImagePost`, `publishMultiImagePost`, `publishVideoPost`, `publishReel`) all included `'message' => $content` (or `'description' => $content`) in the payload regardless. Facebook expects the key to be omitted, not null.

Fix: conditionally include the key only when content is non-empty.

Bug B — `PostPlatform` state transitions leak stale fields

`markAsPublished` did not clear `error_message`/`error_context` from a prior failed attempt. `markAsFailed` did not clear `platform_post_id`/`platform_url` from a prior published attempt. This caused the contradictory `status=published + error_message=set` row.

Fix: each transition now explicitly nulls the opposite side's fields.

Bug C — failed posts are still re-publishable

`Edit.vue::isReadOnly` did not include `'failed'`, so the UI re-enabled the Publish button after a failure. The customer (or anyone) could re-click and:

• Generate duplicate "failed to publish" emails
• Trigger a second job that, if successful, set publish fields but left the old error_message (Bug B)

Fix:

• Frontend: `'failed'` added to `isReadOnly`
• Backend: `UpdatePost::execute` rejects any mutation when status is `Published`, `PartiallyPublished`, `Failed`, or `Publishing` via a new `PostAction::Finalized` case. Defense-in-depth — frontend lock alone is not enough.

To retry a failed post, the user duplicates it (existing flow).

Tests (11 new — regression guarantee)

• `FacebookPublisherTest` (4): each publish path asserts the key (`message` or `description`) is absent from the Graph API payload when content is null
• `PostPlatformTest` (2): `markAsPublished` clears error fields; `markAsFailed` clears publish fields
• `PostControllerTest` (4): re-publish blocked for each terminal status; `Bus::assertNotDispatched` confirms no duplicate job
• Plus updates to 2 existing edit-redirect tests

If anyone removes the empty-message guard, the field-clearing, or the terminal block in the future, the build fails before merge.

Test plan

• Full suite: 1552 passing, 0 failures
• Pint clean
• Manual: post FB Page with media + no text → submit → FB succeeds (no 'post is empty' error)
• Manual: post fails for any reason → Publish button is disabled → can only Duplicate

Out of scope

• Notification dedupe (if the customer already got a failure email, no follow-up success email is sent — that's an existing behavior, can be revisited)