Fix RDP/VNC clipboard sync randomly stopping

Local copies were de-duplicated against the last synced text with no
expiry, so one lost send made re-copying the same text a no-op; every
open tab listened to the system clipboard, letting background sessions
overwrite it and forwarding one tab's update to all others; and RDP
never sent the initial Format List MS-RDPECLIP requires after Monitor
Ready, which the server can re-send mid-session (e.g. rdpclip.exe
restart), leaving sync dead until reconnect. Announce failures are now
logged to the event log instead of silently dropped.

Bump version to v2026.9.26.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/PROGRESS.md

@@ -226,6 +226,22 @@ Delivered:
   dark mode -- its perceived luminance was well below the four existing
   state colors -- and was replaced with `#ab47bc`, tuned to roughly
   match their visibility
+- Clipboard sync (RDP/VNC) randomly stopping, reported on Windows and
+  Linux: (1) `SessionTab` de-duplicated local copies against the last text
+  it had synced, with no expiry, so once one send was lost (channel not
+  ready, remote clipboard changed to something it never saw) re-copying
+  the same text did nothing indefinitely -- it now suppresses only the
+  echo of its own clipboard write, for one second; (2) every open tab
+  listened to the system clipboard, so a background session re-announcing
+  its stale clipboard overwrote what was just copied and one tab's update
+  was forwarded to every other connected session -- only the visible tab
+  syncs now; (3) RDP answered Monitor Ready with capabilities but never
+  the initial Format List MS-RDPECLIP requires, and the server can send
+  Monitor Ready again mid-session (e.g. rdpclip.exe restarting), leaving
+  sync dead until reconnect -- it now always sends one; announce failures
+  and not-yet-ready-channel copies are logged to the session event log
+  (with a line per copy sent/received) instead of silently dropped. Not
+  reproduced locally; needs confirmation from real use
 - Robustness fix: an unrecognized `FramebufferUpdate` rectangle encoding
   used to abort the connection generically; `kAnnouncedEncodings` is now
   the single source of truth for what `SetEncodings` announces and what