fix: support CJK characters in MinHash fuzzy deduplication

[Lucas5357]

Summary

• _normalize_name_for_fuzzy() uses regex [^a-z0-9' ] which strips all non-ASCII characters, making MinHash/Jaccard similarity always return 0.0 for CJK (Chinese, Japanese, Korean) entity names
• Replace with [^\w' ] to preserve Unicode word characters
• Add adaptive n-gram: 2-gram shingles for CJK text (each character carries more semantic weight) vs unchanged 3-gram for Latin
• Add 8 unit tests covering CJK normalization, shingle generation, similarity scoring, and entity resolution

Context

The existing Embedding + LLM layers already handle CJK entity resolution end-to-end, so the overall system still works. However, the MinHash fast-path silently falls through to LLM for every CJK entity pair, adding unnecessary latency and cost. This fix restores the deterministic fast-path for CJK scripts.

Test plan

• All 31 existing + new tests pass (pytest tests/utils/maintenance/test_node_operations.py)
• Latin text behaviour unchanged (3-gram shingles, same normalization)
• CJK normalization preserves characters (was stripped to empty string before)
• CJK 2-gram shingles produce correct sets
• End-to-end Jaccard similarity > 0 for similar CJK names
• Exact CJK name match resolves deterministically
• Short CJK names correctly defer to LLM (entropy filter)

[danielchalef]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

---

I have read the CLA Document and I hereby sign the CLA

---

潘彥廷 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.}