fix(macos): recover runtime SQLCipher codec keys

[RPGboy2023]

Summary

• add an arm64 Mach-O instruction-pattern locator for newer macOS WeChat builds that no longer expose every key as x'<key><salt>'
• capture transient SQLCipher derived AES/HMAC key pairs through LLDB and independently verify both keys against encrypted page 1 before accepting them
• re-verify and preserve existing keys, isolate legacy scanner output, and atomically replace all_keys.json only when at least one valid key remains
• decrypt main/WAL pages with HMAC verification for derived-key entries
• discover both message_N.db and biz_message_N.db shards

Safety properties

• no fixed WeChat version offset, account path, database shard number, or key material
• the hook must match exactly one arm64 instruction sequence or the fallback fails closed
• capture output is created with mode 0600; key bytes are never printed by the fallback
• failed or empty scans do not erase previously verified keys
• an outer LLDB timeout sends SIGCONT so WeChat is not left suspended

Verification

• python3 -m unittest discover -s tests -v (6 tests pass)
• Python 3.12 compileall passes
• CLI --help smoke test passes
• wheel builds with Python 3.12 and includes the LLDB helper while excluding tests/build artifacts
• the locator uniquely resolves the installed WeChat arm64 dylib to the same hook previously found by manual analysis
• a real derived-key entry decrypts the corresponding message database through DBCache; SQLite PRAGMA quick_check returns ok
• full extraction regression on a temporary copy: the legacy scanner returned zero candidates, while all 28 previously saved keys were re-verified and preserved

Runtime note

The codec fallback observes live page processing. If the target database is idle during the bounded capture window it reports a timeout and leaves the key file unchanged; opening/using the relevant chat while init runs provides the required page activity.