1.0.10

Fixed (#370)

• Ответ пользователя на ask_user больше не исчезает из диалога после перезагрузки (#370, найдено при аудите #369): ответ персистился role='tool'-строкой (LLM-семантика: tool-результат в паре с tool_call), которую uiRoleFilter исключал из API истории — после F5 бабл ответа пропадал, а в live-режиме оптимистичная запись висела неподтверждённой (эхо message_persisted для этого персист-сайта не публиковалось, answerAskUser не слал client_temp_id). Строка осознанно остаётся единственной role='tool' (двойная персистенция дала бы три копии ответа в контексте возобновлённого хода, новая роль потребовала бы миграций в обе СУБД и сломала бы findPendingAskUser/GetPendingAsk/PatchToolCallsMessages); изменена видимость и подтверждение: (1) uiRoleFilter/pgUIRoleFilter возвращают role='tool' AND tool_name='ask_user' (прочие tool-строки скрыты как раньше, ретроактивно в истории всплывают и старые ask-ответы); (2) хендлер истории маппит такие строки в role='user' на границе API (tool_name='ask_user' сохраняется как маркер, content/media/user_id/client_temp_id уже на строке); (3) ask-ветка actor’а проставляет ClientTempID на строке и публикует message_persisted-эхо user-лейна ({client_temp_id, persisted_msg_id}, как persistUserMessageOnReceive; без temp id — неинтерактивные каналы — эхо не шлётся); (4) answerAskUser генерирует и шлёт client_temp_id, штампует его на оптимистичной записи — свап server id по эху работает действующим user-бранчем клиента. Тесты: store — видимость ask-ответа в GetRecentUIMessages/GetUIMessagesBefore при скрытых обычных tool-строках и пустых carrier’ах; handler — маппинг в role='user' с сохранением маркера; actor — персист tool-строки с ClientTempID + ровно одно эхо с id строки, отсутствие эха без temp id; TS — client_temp_id в WS-фрейме и на оптимистичной записи, подтверждение бабла по эху.