fix(keys/macos): report correct key count after init

[colin4k]

Summary

wechat-cli init on macOS reports 提取到 0 个密钥 even when key extraction succeeds and all_keys.json is written with valid entries, which makes users think the command failed.

Root cause

The C binary find_all_keys_macos writes entries in this shape (see wechat_cli/bin/find_all_keys_macos.c:309):

{ "sns/sns.db": { "enc_key": "…" } }

It intentionally does not include a salt field. But wechat_cli/keys/scanner_macos.py builds its key_map by filtering entries on both enc_key and salt:

for rel, info in keys_data.items():
    if isinstance(info, dict) and "enc_key" in info and "salt" in info:
        key_map[info["salt"]] = info["enc_key"]

So every entry is filtered out, key_map is empty, and init.py prints 提取到 0 个数据库密钥 via len(key_map).

The all_keys.json file itself is correct, and downstream code (get_key_info in core/key_utils.py) already looks keys up by rel path — not by salt — so subsequent commands work. This was purely a misleading display bug.

Fix

Build key_map keyed by rel path, matching the actual shape produced by the C binary and matching how downstream lookups work.

Test plan

• Run sudo wechat-cli init on macOS with WeChat running
• Verify the summary line now reports the real number of keys (e.g. 提取到 25 个数据库密钥) instead of 0
• Verify subsequent commands (wechat-cli sessions, wechat-cli history, etc.) still work as before
• Confirm ~/.wechat-cli/all_keys.json content is unchanged