Состояние ползунков было write-only: `Section31Settings` держал его у себя и
отдавал обратно в ту же панель, до /analyze оно не доезжало. Пользователь
двигал веса, жал «Применить» и получал ТОТ ЖЕ скор по системным весам —
проверено на проде: park 1.8→3.0, tram −0.5→−2.0, скор 18.91 до и после, за
две минуты ни одного нового POST /analyze.
Веса подняты на страницу и уходят в analyze через `AnalyzeWeightsContext`, а не
пропом: `useParcelAnalyzeQuery` зовут шесть мест (§1, §2, §4, §5, страница,
/ptica) на общем ключе кэша. Проп, забытый в одной секции, развёл бы ключи —
половина страницы считала бы по одним весам, половина по другим, и дорогой
analyze ушёл бы дважды. Контекст держит всех потребителей ключа на одном
значении по построению.
Веса уходят inline, а не через profile_id: тело запроса равно ползункам, ответ
рапортует source="inline". Прод-проверка: park 3.0 / tram −2.0 → 18.91 → 17.95.
Заодно (#2790 п.2): системные пресеты (Эконом / Комфорт / Бизнес) лежали в
проде с 16.05.2026 и не были видны никому — фронт не слал include_system.
Просто включить его было нельзя: пресет с user_id='__system__', выбранный как
profile_id, resolve_weights() ищет в области владельца, не находит и молча
берёт дефолты, отвечая source="profile" (#2782). Поэтому пресет теперь не
адресуется по profile_id — его веса уходят inline. Бэкенд не тронут.
Прод-проверка: «Бизнес» → inline metro_stop 2.5 / shop_mall 2.0 → скор 13.13.
П.3: useUpdateProfile / useDeleteProfile удалены. Их не звали ниоткуда, а
спрос за три месяца — 1 профиль на всю базу (admin, updated_at = created_at):
ни одного изменения, ни одной попытки удаления. Эндпоинты живы и покрыты
тестами бэкенда.
Refs #2790
