fix(scanner): preserve all memory keys with _by_salt fallback

[yanicklandry]

Problem

`scan_keys` discarded any key found in WeChat's process memory that didn't match a known DB file's salt. If DB files were inaccessible during `wx init` (permission issues, path resolution failures, files not yet written), zero keys were saved and decryption silently failed with no actionable error.

Fixes #73

Solution

Save all `(key, salt)` pairs found in memory, unconditionally.

• Keys whose salt matches a DB file → stored under the relative DB path as before (`message/message_0.db`, etc.)
• Keys with no matching DB file → stored under `_by_salt/<salt_hex>` so they are never lost

`DbCache::get_with_mode` gains a two-step key lookup:

1. Normal lookup by `rel_key` (existing behaviour, unchanged when it hits)
2. Fallback: reads the DB file's first 16 bytes (the SQLCipher salt), then looks up `_by_salt/` in the key map

背景 / 问题

`scan_keys` 扫描 WeChat 进程内存后，只保留能匹配到本地 DB 文件 salt 的密钥。如果 `wx init` 运行时 DB 文件不可访问（权限问题、路径未检测到等），所有候选密钥都被丢弃，导致解密静默失败，没有任何有效报错。

改动

三个平台扫描器（macOS / Linux / Windows）统一更新：无法按 salt 匹配到 DB 文件的密钥，改为以 `_by_salt/<salt_hex>` 为键保存，不再丢弃。daemon 的 `DbCache::get_with_mode` 增加回退逻辑：按相对路径找不到密钥时，读取 DB 文件头部 16 字节作为 salt，再用 `_by_salt/` 重新查找。

Validation

• `cargo check` — clean
• `cargo test` — 124 passed, 0 failed
• macOS, Linux, Windows scanners all updated consistently
• `sudo ./target/release/wx init --force` — before: `匹配到 0/43 个密钥`, after: `匹配到 29/43 个密钥（另有 14 个按 salt 保存）`
• `./target/release/wx sessions` — decryption works end-to-end