feat(messages): apply refreshed link metadata to posted row

[Adron]

Summary

Closes #96. Stacked on #94 (feat/refresh-link-metadata-after-publish), which must merge first —
this branch is based on it, and its diff is included below the stack base.

#94 fires POST /api/messages/{id}/metadata after publishing and discards the response, so a new
post's link card only appeared on the next feed fetch. The response is now folded into the row that
publish just inserted, through a pure conversion plus one AppDataStore mutation, with no second
request — it reuses the response #94 already receives.

The refresh stays fire-and-forget: a throw, an empty response, or a message that has since left the
feed leaves everything exactly as it was, silently and without a crash. The publish request, the
live-preview-while-composing path, and the metadata call added in #94 are untouched, as is the edit
path (#76).

Two blockers found downstream — read before merging

Neither is introduced here and both are outside this issue's stated scope (ComposeView.swift,
AppDataStore.swift, Message.swift), but the user-visible acceptance criterion ("preview appears
without waiting for a feed refresh") cannot be met until both are fixed:

1. refreshMessageMetadata decodes a shape the route doesn't send. It expects
   { "metadata": { "links": [ { url, title, description, image } ] } }. The route
   (app/api/messages/[id]/metadata/route.ts, backend 8064a1bd) returns { "links": [...] } at
   the top level, and each entry is a full LinkMetadataItem — nested metadata object, thumbnail
   rather than image, plus platform/fetchStatus/fetchedAt. serialize() only normalizes
   values, it never restructures. So against the live API the decode returns [] every time, and the
   existing unit test passes only because its fixture was written to the assumed shape. Fixing it is
   an APIClient.swift change, which this PR deliberately does not make.
2. FeedView doesn't observe in-place row updates. It mirrors store.feedMessages into a local
   @State private var messages and merges only messages whose id it doesn't already have
   (FeedView.swift:385 — the sync is keyed on store.feedMessages.count). Replacing an existing
   row's linkMetadata changes content, not count, so the rendered feed keeps the old value until a
   full reload. The store and its cache are correct; only the view's private copy is stale.

The conversion and the store mutation in this PR are the pieces that will consume both fixes, so
they are worth landing either way — but nothing observable changes until the two above are resolved.

What's included

• LinkMetadataItem.init(preview:) / LinkMetadataItem.from(previews:) in Models/Message.swift —
  pure, no SwiftUI, no networking. image → metadata.thumbnail, title/description pass through
  trimmed. A preview that resolved to nothing (or to whitespace only) converts to an item with
  nil metadata, because LinkPreviewBlock draws a card only for a non-nil metadata and an
  all-nil content object would render an empty grey box. The item itself is kept — its url is what
  the rest of the app reads off a link. platform and fetchStatus stay nil rather than being
  guessed; the flat preview carries neither and nothing renders off them.
• AppDataStore.applyLinkMetadata(_:toMessageId:) — replaces one already-inserted message's
  metadata by id and persists the feed cache. Unknown id: no-op. Empty links: no-op, because the
  route answers { links: [] } for a message it resolved nothing for and blanking a preview a feed
  fetch had already supplied would be a regression, not a refresh.
• Message.linkMetadata becomes var — the only mutable field on the row — so the backfill doesn't
  rebuild all sixteen fields to change one.
• ComposeView.refreshLinkMetadata(for:) applies the response through the store inside
  Task { @MainActor in … }; try? keeps every failure invisible on the publish path.
• Tests: new LinkMetadataConversionTests (10), plus 6 applyLinkMetadata cases in the existing
  AppDataStoreTests. The new file is hand-slotted into project.pbxproj (no re-sort).

Testing

• Full suite, simulator 3E2891BA-FB4E-4EDF-9BF9-1226134E1BC8, serialized, E2E skipped, private
  DerivedData: 1172 tests, 0 failures (1156 on the feat(messages): refresh link metadata after publishing #94 base + 16 new). No new warnings.
• Conversion (10): full mapping; platform/fetchStatus/text/type left nil; order preserved
  across several; empty input; no image and no title → url kept, metadata nil; description-only;
  image-only; all-whitespace fields treated as absent; padded title trimmed; a dead preview alongside
  a live one converted independently.
• Store mutation (6): targets the right message; leaves other rows and feed order untouched;
  replaces existing metadata; unknown id is a no-op; empty feed is a no-op; empty links leaves
  existing metadata intact.
• Mutation-checked that the new tests bite: inverting the nil-metadata rule in the conversion and
  making the store write to index 0 regardless of id produced 5 failures across exactly the
  intended tests (3 conversion, 2 store); both edits were reverted and the full suite re-run green.

Not verified

• The live end-to-end path — posting a real message with a link and watching the card fill in — is
  blocked by the two items in the Summary and needs a real account plus a real OpenGraph fetch. No
  simulator run can confirm it today.
• That SwiftUI redraws the row once FeedView is fixed to see the update: the store-level change and
  its @Published emission are tested, the rendering is not (and view rendering is out of scope for
  unit tests here).
• The { links: [] } response claim in the empty-links no-op is read from the route source, not
  observed against production.

🤖 Generated with Claude Code