[guiyanakuang]

Problem

Received pastes are persisted as-is, so unlike a local capture they never go through
RemoveInvalidPlugin. A paste carrying an empty text flavor (e.g. a peer that captured
an empty clipboard) was stored, relayed, and handed to the clipboard, where the empty
value replaced whatever the user had copied: pbpaste prints nothing and pasting into
any app yields no content.

Fix

Treat invalid content as a receive policy, next to the existing
discardOversizedRemoteNonFilePaste / discardInvalidRemoteFilePaste:

• PasteData.hasValidContent() extracts the content check out of isValid(), so the
  receiver can judge a paste without depending on its pasteState (isValid() keeps
  its behavior and now delegates to it for LOADED).

• prepareRemotePasteReceive() calls discardInvalidRemotePasteContent(): a paste whose
  content is invalid is dropped before anything is stored, and its remote ID is settled so
  a reconnect does not pull it again. It is logged, not notified — nothing meaningful is
  lost.

• releaseRemotePasteDataForPush() (HTTP push session for files/images) applies the same
  check right after its file-type check, before reserving the cursor or creating a row.
  validateFileTransferMetadata alone does not imply PasteFiles.isValid() (a zero-byte
  file or an empty hash passes it).

Every receive entry — WS push, pull, history pull and HTTP file push — is now checked
before anything is stored, so the invalid paste never becomes a hidden row, is never
relayed to other devices, and never reaches the clipboard. Finalize
(releaseRemotePasteDataWithFile) needs no extra guard: its rows only come from these
entries, and receives interrupted by an older build are discarded at startup by
discardInterruptedReceives().

Like the existing oversized discard, a discarded paste is reported back as rejected, so
the sender records one non-retried sync failure for it. This is intentional: it is a
receiver policy decision, not a transport error. PasteReleaseService
and PasteData are in commonMain, so this applies to desktop and mobile alike.

Tests

• PasteReleaseServiceRemoteDiscardTest: an empty-text remote paste is discarded — no task
  submitted, no clipboard write, cursor settled, no notification. The "within limit" test
  now runs the submitted block and asserts the clipboard write actually happens.
• File pastes whose metadata is valid but content is not (a zero-byte file): discarded on
  the pull path before any download (no task, cursor settled, no clipboard write), and
  rejected on the HTTP push path before the cursor is reserved or a row is created.

./gradlew app:desktopTest (fast tier) passes; ktlintFormat clean.