fix: improve SQLite clipboard history persistence

[tingkai-c]

Summary

Improve the reliability and startup behavior of SQLite-backed clipboard history.

The initial SQLite implementation loaded clipboard history synchronously before the launcher window could open. Histories containing large image blobs added database I/O and attempted image decoding to the startup path, making the launcher feel less snappy.

What Was Happening

• up to 300 clipboard entries were loaded before the first window opened
• image blobs were copied and decoded synchronously
• raw RGBA pixels were incorrectly treated as encoded image files
• the complete clipboard history was cloned when rendering its page
• persisted entries were not updated when history was reordered, edited, deleted, or cleared
• the database could grow beyond the in-memory 300-entry limit

Changes

• load persisted clipboard history in the background so it does not block the initial launcher opening
• store raw RGBA images with their width and height, avoiding image-format detection and decoding
• prevent stale background loads from overwriting newer clipboard changes
• avoid cloning the complete clipboard history during rendering
• persist duplicate reordering, updates, deletion, and clearing
• use transactions for replacement and update operations
• limit the database to 300 clipboard entries
• enable SQLite WAL mode with normal synchronization
• migrate existing databases once using SQLite user_version
• add migration, image round-trip, history limit, and persistence tests

Migration

Existing text and URL entries are preserved.

Legacy image entries cannot be recovered because they were stored as raw pixels without their dimensions. These invalid entries are removed during the one-time migration instead of continuing to occupy the history limit.

Testing

• cargo +stable fmt --check
• cargo +stable clippy --all-targets --all-features
• cargo +stable test
• verified all 52 tests pass

[unsecretised]

Please open an issue first before working on a PR since it ensures that an existing maintainer can explain how you should implement a feature, and also please explain why it would be an issue first.

As for the code:
The clipboard history database is still a basic implementation with load more items (among others) to still be meant to be added. If clipboard load times are a problem it can be moved to a Task::perform which can then be loaded asynchronously.

Additionally, you did not mention the AI usage (again) and lacks any communication with the maintainers. For this reason I'm going to close this pull request. Please open an issue first to explain what you're trying to solve first.