feat(image_key): implement Linux V2 AES key derivation via /proc/mem + brute-force fallback

[RoseCamel]

Summary

This PR fills the last remaining platform gap in the image_key module — Linux V2 .dat image AES key extraction.

Approach

Two-path strategy, symmetric with the existing macOS implementation:

Primary: process memory extraction

1. Auto-detect WeChat PID via /proc/<pid>/comm
2. Scan readable memory regions for uin=<base64> URL parameters (where UIN appears base64-encoded in WeChat's network request URLs)
3. Derive AES key: md5(str(uin) + normalize(wxid)).hex()[:16] (16 ASCII bytes, same formula as macOS)
4. Derive XOR key: uin & 0xff
5. Verify against V2 template ciphertexts from the attach directory

Fallback: brute-force enumeration

When /proc/<pid>/mem is unreadable (no CAP_SYS_PTRACE):

1. Extract 4-hex-char wxid suffix from the xwechat_files/<wxid_XXXX> directory name
2. With XOR hint (from .dat tail voting, same as macOS): enumerate 2^24 space — uin & 0xff == xor_key + md5(str(uin))[:4] == suffix — verify each candidate against AES templates
3. Without XOR hint: full range enumeration (10,000 ~ 50,000,000)

Changes

• src/attachment/image_key/linux.rs: 438-line implementation replacing the 6-line stub
• src/attachment/image_key/mod.rs: one-line fix to call ::from_current_config() constructor

Verification

• cargo check — compiles cleanly
• cargo test image_key — 8/8 tests pass, including known-value key derivation verification
• No new dependencies (all crates already in Cargo.toml)
• Reuses existing shared infrastructure: verify_aes_key(), find_v2_template_ciphertexts(), derive_xor_key_from_v2_dat(), normalize_wxid()

Notes for reviewer

The implementation deliberately mirrors the macOS provider's structure — same caching pattern, same derive_key_for_paths → find_via_* → bruteforce_* flow, same ImageKeyProvider trait impl shape. This keeps the three platform providers easy to compare and maintain in parallel.