Defer clipboard inspection until focused

[gpertea]

Summary

Defer plain-text clipboard inspection while the viewer is unfocused. TigerVNC already delays advertising the client clipboard until focus returns; this change also delays Fl::clipboard_contains() until that point.

This avoids unnecessary platform clipboard access from every unfocused viewer and prevents a transient failed format check from immediately being treated as a non-text clipboard.

Scope

This addresses the unfocused clipboard-inspection and contention path described in #2128. It does not change how FLTK delivers clipboard-change notifications, retry failed clipboard access, or recover notifications lost by the Windows clipboard-viewer chain.

The source != 0 check is retained, preserving the PRIMARY-selection behavior fixed by #2129.

Addresses #2128.

[CendioOssman]

Thank you for your suggestion.

I think we just add needless complexity and confusion by making this Windows-only. Please adjust the commit so that this behaviour is the standard one.

[gpertea]

Thanks, agreed. I've removed the Windows-specific branch, so clipboard inspection is now deferred consistently across platforms. I also rebased onto current master while preserving the new PRIMARY-selection handling from #2129. Tested on Windows and headless X11/Linux.

[gpertea]

Please hold off on reviewing this for now - I've converted the PR back to draft.

Further live testing exposed a remaining Windows clipboard failure. The patch addresses clipboard inspection/contention after a notification is received, but it does not address loss of notifications caused by FLTK’s Windows clipboard-viewer chain. I need to separate those behaviors and reassess the scope before requesting review again.

[gpertea]

Further testing confirmed that this patch has a narrower scope than I initially thought: it avoids immediate clipboard inspection by an unfocused viewer, reducing contention and preventing a transient failed check from discarding a notification that was received.

However it does not address missed Windows clipboard notifications caused by FLTK's own clipboard-viewer chain. I've updated the PR description accordingly, rebased onto current master, preserved the #2129 behavior and tightened the clipboardSource assignment. So this is intended as a targeted improvement, not a complete fix for Windows clipboard reliability, which requires a platform specific fix in FLTK.