re add tokio pipes, but fetch sequentially

[wiiznokes]

Please explain briefly what the PR does.

[GonzRon]

Please explain briefly what the PR does.

I looked into it because I switched to clipboard-manager from copyq on Cosmic desktop.

● This PR directly addresses the exact class of bug that was crashing your system. Here's what it does:

PR #170: "re add tokio pipes, but fetch sequentially"

Problem it fixes: When reading clipboard data from Wayland pipes, the old code used blocking synchronous std::io::pipe reads (pipe.read_to_end()). If the source app was slow or unresponsive, this would block indefinitely, hanging the clipboard watcher.

What it changes (3 files, +29/-52 lines):

1. clipboard_watcher.rs — Switches from std::io::pipe() (blocking) to tokio::net::unix::pipe::pipe() (async). This means pipe reads are non-blocking and can be cancelled.
   Also cleans up the SeatData struct by using mem::replace instead of take-then-assign, and removes an unused events: Vec field that was accumulating data offer events
   without being consumed.
2. clipboard.rs — Wraps each pipe read in a 500ms timeout (tokio::time::timeout(Duration::from_millis(500), pipe.read_to_end(...))). If a clipboard source doesn't deliver
   data within 500ms, it logs a warning and moves on instead of blocking forever. The reads are also now async (AsyncReadExt instead of std::io::Read).
3. .gitignore — Adds the db lock file.

In short: This is exactly the kind of fix CopyQ is missing — it prevents clipboard pipe reads from blocking indefinitely by using async I/O with a 500ms timeout, which prevents the process accumulation and resource exhaustion that was crashing your Electron apps via D-Bus FD exhaustion.