Разбирая неоднозначные ядра, find_geo_matches геокодил ВСЕХ objective-кандидатов,
включая тех, чьё имя уже занято в objective_complex_mapping. Записать такое имя
нельзя в принципе: apply_geo_matches вставляет с
ON CONFLICT (objective_complex_name, objective_group) DO NOTHING, а _TAKEN_NAMES_SQL
выбирает ровно по этому ключу.
Последствия на боевом пути:
- занятый кандидат мог оказаться единственным в радиусе и уходил в confirmed —
прогон рапортовал подтверждение, за которым запись молча не делала ничего;
- занятый рядом со свободным давал «двое в радиусе» → ambiguous_multi, хотя
выбор был единственным;
- квота DaData (лимит 200 вызовов за прогон) тратилась на заведомо непишущихся.
Замер на проде 19.08: 930 несопоставленных domrf ЕКБ-объектов, из них 14
неоднозначных; 28 слотов кандидатов, 14 занятых; 3 из 6 разных адресов к геокоду
принадлежали занятым. После отсева у всех 14 остаётся ровно один кандидат.
Заодно причина отказа перестаёт врать: при пустом in_radius это 'too_far', а не
'ambiguous_multi'; когда заняты все кандидаты — отдельная 'all_candidates_taken'.
После отсева случай «остался один кандидат» становится частым, и старая метка
читалась бы оператором как факт неоднозначности.
