Clipboard listener hangs/becomes unresponsive when history contains extremely large strings.

[nairadithya]

If a user copies an extremely large block of text (in my case, an 18MB string of raw SVG data), clipse saves the entire payload into ~/.config/clipse/clipboard_history.json. Because of the massive file size, the clipse -listen daemon (running via wl-paste --watch) begins to choke. Subsequent clipboard operations either take an extremely long time or fail entirely because clipse struggles to synchronously parse, append, and rewrite the 18MB+ JSON file on every new copy.

Steps to reproduce the behavior:

1. Run clipse -listen in the background (standard setup with wl-paste --watch).
2. Copy a massive text payload to the clipboard (e.g., an 18MB+ text file or SVG).
3. Try to copy a normal string (e.g., "hello world").
4. The clipboard becomes unresponsive, hangs, or fails to record new entries promptly.

Expected behavior
clipse should not block the system clipboard when dealing with large payloads. It should ideally:

1. Have a hardcoded or configurable size limit (e.g., 2MB) for text entries being saved to the history JSON.
2. Gracefully ignore or truncate entries that exceed this limit to prevent clipboard_history.json from bloating.

System Settings:

1. OS: Linux
2. Environment: Hyprland
3. Clipboard: wl-clipboard

Note: I restarted the clipse instance after removing the large entry from clipboard_history.json using jq and then rerunning clipse -listen.

[cheneyni-451]

Another solution could be to use a SQLite database instead of a JSON file. I also noticed that trying to paste a very long string would fail and show an error message:

logger.go:21: ERROR: fork/exec /usr/bin/wl-copy: argument list too long

But this can be fixed by not passing the string directly as a command line argument to wl-copy.