[Feature] Оптимизация Orders getList: conditional Address JOIN + stats endpoint

[Ibochkarev]

Описание функции

Ускорить manager list заказов: Address leftJoin только когда нужен фильтрам/сортировке/колонкам; агрегаты stats вынести из критического path list (отдельный endpoint или opt-in flag).

Проблема, которую решает

В OrdersController::getList (сейчас толстый класс, цель распила — #338) типичный path:

1. leftJoin Address всегда
2. Отдельный COUNT(DISTINCT …) clone
3. Полный SELECT
4. getOrdersStats — ещё один SUM/COUNT с другим набором статусов

Три тяжёлых запроса + лишний JOIN на каждый page load грида. Рефакторинг в сервисы (#338) без этой правки просто перенесёт стоимость.

Предлагаемое решение

Code judo после (или внутри) выделения ManagerOrderQueryService:

1. Детект: нужны ли address-поля в filter/sort/select columns → JOIN только тогда.
2. Stats: GET /api/mgr/orders/stats (или ?include_stats=1 по умолчанию off для list). Vue OrdersGrid грузит stats параллельно / лениво.
3. Сохранить JSON-shape строк списка (breaking change колонок — нет).
4. Документировать контракт stats в PR.

Не оптимизировать микро-индексами вслепую без EXPLAIN на реальных данных — сначала убрать лишнюю работу.

Альтернативные варианты

• Всегда JOIN, только индексы БД — не убирает COUNT+stats tax.
• Материализованная stats-таблица — раньше времени.

Критерии приёмки

• List без address-фильтров не делает Address JOIN (проверка query/log или unit на builder).
• Stats не блокирует TTFB списка или явно opt-in и задокументирован.
• Vue Orders grid: цифры stats и строки списка совпадают с прежним UX (ручной чеклист).
• Связка с [Feature] Распилить OrdersController: thin controller + сервисы (<1000 LOC) #338: логика живёт в Query service, не в тонком контроллере.

Дополнительный контекст

Связано: #338 (decompose), memo GridConfig (соседний issue). Не трогать storefront OrderDraft path.