REL-4: Аудит мутаций

[ii-reviewer]

Цель: иметь неизменяемый след «кто/что/когда менял» для разбора инцидентов и подотчётности.
Зависимость: #1, #2, #3, #5, #6, USR-1.

Что сделать

• Таблица audit_log: кто (user_id/username), действие (CREATE/UPDATE/DELETE/RECEIVE/WRITE_OFF/DEACTIVATE), сущность + id, старое → новое значение (diff или JSON-снимок), когда.
• Покрыть: создание/редактирование/удаление товара, движения, деактивацию пользователя.
• Выбрать механизм и обосновать:
  • Spring AOP — @Around/@AfterReturning на сервисных методах, ручной сбор diff;
  • Hibernate Envers — @Audited на entity, авто-таблицы _aud.
• Писать аудит так, чтобы он не терялся при откате полезной транзакции и не ломал основную операцию при сбое записи лога (решить: в той же транзакции или асинхронно — с осознанием рисков).
• Стретч: лог неизменяемый (только INSERT; запретить UPDATE/DELETE правами БД или дизайном); сравнить AOP vs Envers по полноте и стоимости.

Acceptance criteria

• Каждая из перечисленных мутаций оставляет запись с актором, временем, старым и новым состоянием.
• По товару/пользователю можно поднять хронологию изменений.
• Записи аудита нельзя изменить/удалить штатным путём.
• Откат бизнес-операции не оставляет «фантомных» записей аудита (или это явно задокументировано).
• В PR обоснован выбор AOP vs Envers.