Cross-posting: surface failures and reply-threading behaviour #43

Part of #38 — Social account linking (OAuth) and full cross-post destination support

Web behaviour: if cross-posting fails, a transient error appears for ~5 seconds and the post
still lands on InterlinedList. When replying to a cross-posted message, if the user follows
the original author on that platform, the reply may be cross-posted automatically.

There is no dedicated cross-post status endpoint — status rides the message-create response
(crossPosts in the POST /api/messages body).

What already works

The per-network status is handled: CreateMessageResponse parses crossPosts into
CrossPostStatusDto, MessagesFeedViewModel exposes crossPostStatuses, and
MessagesFeedScreen renders a CrossPostStatusBanner on post. That half of this issue is done —
it is recorded here so the epic's coverage is accurate.

What is left

• Replies. The status banner is wired into the feed composer. Verify the reply composer and
  the scheduled-post path surface it too, since a reply to a cross-posted message may be
  syndicated automatically and can fail the same way.
• Stale-connection cause. A failure caused by an expired connection should point at
  re-verification rather than reading as a transient glitch — see the unlink/re-verify sub-issue.
• Scheduled posts fire their cross-posts later, when no banner can be shown. Decide how a
  failure that happens hours after composing reaches the user at all (a notification, or a marker
  on the published message).

Tests: reply path surfaces a failed network; scheduled-post failure is discoverable after the
fact.

Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.