[Feature] Boundary: Domain facades vs Controllers/Api (naming + AGENTS)

[Ibochkarev]

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

Зафиксировать и (опционально) выровнять naming boundary:

• HTTP: Controllers/Api/Manager/*, Controllers/Api/Web/*
• Domain facades (MS2-style): Controllers/Cart, Controllers/Order, Controllers/Customer, Delivery/Payment…

Сейчас оба живут под Controllers/ — disinformation для ревью и агентов.

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

Clean Code: имя вводит в заблуждение. Контрибьютор кладёт HTTP-логику в domain facade или наоборот. Аудит тратит время на объяснение «это не контроллер».

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

Минимум (docs)

1. Секция в README/AGENTS (то, что коммитится) или docs/комментарий в ServiceRegistry: таблица «ключ DI → класс → роль».
2. PHPDoc на Cart/Order/Customer: «Domain facade, не HTTP controller».

Опционально (rename, отдельный PR)

• MiniShop3\Domain\Cart\Cart (или Facades\) + alias/bc layer на один major.
• Обновить ms3_cart / class settings overrides.

Не смешивать rename с #362 (thin facade) в одном PR, если rename большой.

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

• Ничего не делать — только устное знание maintainers.
• Rename без docs — ломает кастомные extends у сайтов.

Примеры использования

Ревьюер видит Controllers/Api/... = HTTP; Domain/... или явный PHPDoc = facade для $ms3->cart.

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

• Документированная таблица слоёв в репозитории (README или принятый docs-path).
• PHPDoc на трёх фасадах.
• Если rename — changelog note + bc aliases; иначе закрыть docs-only.

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

Tracker #361. Зависит логически от стабилизации #362.