perf(entity-resolution): exclude label entities from the trigram fuzzy-match index

[nicoloboschi]

Closes #3208.

Label entities (values of entity_labels config groups) resolve by exact match only, yet their rows were still covered by the shared trigram index — every fuzzy probe for a regular entity pulled them into its candidate set only to discard them in the bitmap recheck. On banks where a free-text label group accumulated tens of thousands of mutually-similar values, this recheck-discard overhead dominated database CPU under ingest bursts.

What changed

• entities.entity_kind ('regular'/'label', CHECK-constrained, both dialects), set at insert time by the resolver — which already knows the classification. A kind column rather than a boolean so future entity kinds don't need another schema change. The Phase-2 reassert carries the kind on ResolvedEntity, so a label parent pruned between phases resurrects as a label instead of silently re-entering the index.
• Partial trigram index: entities_canonical_name_lower_trgm_nonlabel_idx ... WHERE entity_kind != 'label' replaces the full index. Built CONCURRENTLY (autocommit block, invalid-leftover sweep, create-before-drop so fuzzy probes never lose coverage), skipped when pg_trgm is absent. The trigram candidate query gains the textually-matching AND e.entity_kind != 'label' predicate; the Oracle UTL_MATCH fuzzy scan gets the same filter (no index there, but the same wasted-scan semantics).
• Backfill: the migration classifies each bank's existing canonical_names against that bank's entity_labels config using the same is_label_entity() the resolver uses — no SQL reimplementation of the enum/text/map rules. Banks top out at 10–20k entities, so the synchronous per-bank backfill is fine. Label configs supplied only by a tenant extension can't be seen by the migration; those rows stay regular, which costs index size but never correctness.
• Bug fix uncovered by testing: label classification was gated on the enum lookup set being non-empty. A config with only text/map groups builds an empty set, so its labels were never recognised — neither by the perf(entity-resolution): skip fuzzy probing for exact-match-only label entities #3187 exact-lookup split nor by the new insert-time kind. The gate is now on the config itself. Relatedly, the full fallback strategy could fuzzy-merge a regular text into a label row (e.g. topic empathy → topic:empathy clears the 0.6 threshold with temporal proximity); the scoring loop now skips label-classified candidates, matching what the SQL probes enforce.

Bank import needs no changes: transfer archives treat entities as derived data and re-resolve them through the standard retain Phase 1, which now stamps the kind. Admin backup/restore is likewise unaffected — restore COPYs by the backup's column list, so entity_kind fills from its default for older backups.

Expected impact

• Trigram index size drops in proportion to label-row share (>60% in the observed bank).
• Fuzzy probe candidate sets return to normal size — probe cost drops by roughly the recheck-discard ratio.
• Structurally prevents any text-label-heavy bank from degrading fuzzy matching for its own regular entities.

Tests

• test_migration_entity_kind.py (dedicated pg0): backfill classifies exactly the configured label rows (enum + free-text groups, unconfigured banks untouched), partial index replaces the old one, downgrade restores the full index and drops the column.
• test_entity_resolver.py: end-to-end insert + reassert keep entity_kind='label' on a live PG; new unit test pins that fuzzy scoring never merges a regular text into a label row.
• test_entity_resolver_pg_trgm.py: the fuzzy probe SQL carries the partial-index predicate; the exact label lookup doesn't.

Known tradeoff (documented in the docs + migration): the kind freezes classification at insert time. Removing a label group later leaves its ex-label rows out of the fuzzy index (exact match still works); rows created before a group existed stay in the index (overhead only).