refactor: replace the archived rookie crate with a native chrome cookie reader

[clearloop]

What

Replaces the archived rookie crate with a small native reader for Chrome's cookie store in src/plugins/chrome.rs. leetcode-cli only needs two cookies (LEETCODE_SESSION, csrftoken) from one browser, so this reuses the SQLite already pulled in by diesel to read the cookie DB and implements Chrome's value decryption directly.

Why

rookie is archived and a little rough (its build script unwrap()s git rev-parse, which panics in environments without git). More importantly it pulled a second SQLite client (rusqlite) onto the shared libsqlite3-sys, plus dbus (zbus/zvariant) and aes-gcm. Reading the cookie DB through diesel collapses that to a single SQLite stack and drops the dbus linkage.

Result

• One SQLite client (diesel only); bundled stays active via the explicit libsqlite3-sys dependency.
• Dependency tree drops from 594 to 517 entries and Cargo.lock shrinks by ~1.5k lines; adds four small crypto crates (aes, cbc, pbkdf2, sha1).
• No more zbus/dbus linkage.

Platforms

Automatic Chrome cookies work on macOS and Linux (Keychain / Secret Service password -> PBKDF2-SHA1 -> AES-128-CBC). On Windows, Chrome's DPAPI + AES-GCM (and app-bound encryption on Chrome 127+) isn't implemented yet, so Windows falls back to manual csrf/session in the config. README and docs/cookies.md are updated accordingly.

Testing

cargo build, cargo clippy --all-features, and cargo fmt --check pass, and a clean Linux build with no system libsqlite3 still produces a self-contained binary. The decryption follows Chrome's documented scheme but has not been smoke-tested against a live Chrome profile yet — worth a manual check before relying on it.

Notes

This came out of the #226 SQLite build investigation and removes the second SQLite stack, but it does not by itself fix the AUR build failure reported there.