fix(clipboard): do not let stale remote echo fallback suppress local captures

[mkdir700]

Problem

A fresh local clipboard change can be incorrectly attributed to an earlier remote write and silently skipped.

Evidence

In a dev run, a remote image was written to the local clipboard twice. Each write armed both a content guard and a 60-second ByNextChange remote fallback. The first platform callback consumed one fallback. A later, unrelated local image-file copy arrived 48 seconds after the second write; its files: guard key did not match the remote image key, but the remaining ByNextChange fallback still classified it as RemotePush. The host clipboard runtime then returned before capture, persistence, and outbound dispatch.

This is not a transport failure or a clipboard read failure. The new local snapshot was read successfully before it was misattributed.

Root Cause

SelfWriteMatch::ByNextChange is content-agnostic. It consumes the next observed clipboard event within its TTL regardless of whether that event was caused by the programmatic write it backs. Repeated remote writes can leave such a fallback armed after one callback has already occurred.

Required Change

Replace the content-agnostic next-change fallback with an exact self-write identity that survives platform image re-encoding. The identity must distinguish the programmatic write from a later user copy.

• Keep echo suppression for remote pushes and local restores.
• Remove ByNextChange and all queue/coalescing behavior that exists solely for it.
• Do not use a time-window or an arbitrary next-event heuristic as a replacement.
• The identity must not be persisted, synced, exposed to users, or included in clipboard history.
• Keep ownership in Engine; desktop should only adopt the resulting Engine revision.

Acceptance Criteria

• A remote image write followed by its platform echo does not create a local capture or send a loopback update.
• A later unrelated local copy is captured even when it occurs within the former 60-second fallback lifetime.
• A local image-file copy is covered, because its observed file-based key differs from an earlier remote image key.
• Windows image re-encoding still does not produce a loopback capture.
• Remove legacy fallback tests and add focused regression coverage for the sequence above.
• Run the focused Engine tests and a desktop dev validation: receive a remote image, then create a new local screenshot/image copy; exactly the local item is captured.