thalarch-entity-matchinglisted

# Thalarch Entity Matching Automatic identity resolution should optimize for correctness, not for always returning something. ## 1. Define the identity contract Before scoring candidates, identify: - the source identity fields; - which fields are authoritative vs optional; - which differences are harmless formatting changes; - which differences change semantic identity; - whether false positives or false negatives are more damaging; - what fallback happens when no confident match exists. For automatic playback/import/sync, a false positive is often worse than a clean miss. ## 2. Narrow server-side first When the provider exposes a specific result class/filter/shelf, use it before local fuzzy scoring. Examples: - songs rather than mixed search; - artists rather than generic web results; - exact catalog type rather than all entities. Do not compensate for an unnecessarily broad server query with increasingly fragile local heuristics. ## 3. Canonicalization Reuse the project's existing normalization utilities before inventing new ones. When needed, normalize deliberately: - Unicode letters/numbers rather than ASCII-only `\w` assumptions; - case; - punctuation and spacing; - canonical/compatibility forms where appropriate; - diacritics only when the product's matching semantics permit it; - common connector variants such as `&` / `and` when justified; - artist lists and featuring syntax; - token order when order is not identity-bearing. Canonicalization must be ide