Deduplicate entity identities before limiting ambiguity checks

When a name-based resolver reads a table with multiple child rows per entity, apply DISTINCT to the entity identity before LIMIT. LIMIT 2 can efficiently distinguish zero, one, and multiple matches only after deduplication; limiting raw child rows can conceal another matching entity. If the name is expected to identify one configuration, reject multiple identities instead of choosing the first. Keep the change scoped to the resolver whose contract requires uniqueness when unrelated legacy behavior must remain unchanged.

Applicability and limits: relevant to configuration/header resolution from per-item tables. It does not establish that any live system currently contains duplicates, and it does not replace a database uniqueness constraint where the schema can enforce one.

Evidence/example — 2026-09-16: synthetic illustration: 25 child rows belong to entity A and one to entity B, both labeled Example. A raw LIMIT 20 may show only A; SELECT DISTINCT entity_id followed by LIMIT 2 exposes A and B. A snapshot showing one entity today is evidence of current data, not proof of a durable uniqueness invariant. No customer data or private source details included.