5 час уже непрерывного гуглежа и долбежки об стену, без результата. Вот сюда поэтому и пришел.

Вот еще что заметил:
Если ввести емейл, который уже есть в базе, то бин инжектится в валидатор как надо, то есть всё работает. А если емейла в базе нет, то бин не инжектится.

Вот код.

Все должно работать "из коробки". Спринг создает валидатор через фактори и сам прописывает туда себя, как создателя тех самых инстансов валидаторов. Поэтому инжекшн любым способом должен работать. Если хибернейт валидатор ругается на то, что ему нужен дефолтный конструктор, значит это хибернейт пытается создать валидатор, а не спринг. Значит, вероятно, что-то не верно сконфигурировано.

Возможно, каким-то образом в контексте 2 разных валидатор-фактори образовалось. Один создает валидаторы, как бины. А другой - через стандартную фабрику хибернейт-валидатора..

Но это все касается лишь валидейшен фактори, которую создает спринг. Для себя. Для валидации входящих данных в контроллере, например.

У вас как видно @Entity. А тут уже вступает в силу хибернейт (который имплементирует JPA, а не хибернейт-валидатор). А как там хибернейт создает ValidationFactory - кто его знает. Возможно он сам внутри ее создает и поэтому спринга там нет.

Я имею ввиду если валидировать через entityManager.persist().
если же валидирует контроллер, тогда Энтити это или нет - не важно.

И должно работать.

Просто перед сохранением пользователя проверь имейл в базе и если такой существует отдавай 409. Это как альтернатива

Одну минутку, пытаюсь переделать таким образом, что бы с фронта приходил дто, а не энтити. О результатах отпишусь.

По идее можно что-то вроде Executor.execute сделать, а сам экзекутор взять из потоков спринга

это не имеет значения. Я просто думал вы пытаетесь валидировать ентити при сохранении хибером. Если же вы валидируете контроллером, то есть там аннотация @Entity над моделью или нет - не имеет значения.

Это вы о чем?

Я бы посоветовал добавить конструктор в валидатор, стать туда дебаггером и посмотреть стектрейс, кто этот объект создает и когда.

Изменил в контроллерах энтити на DTO и всё заработало. Спасибо за помощь.

Для начала понять, почему проблема  возникает. Все по той же ссылке есть 2 основаные причины: запрос просто вернул ничего. Это нормально и с этим ничего делать не надо (если для вашего кейса это нормально)
Второй - скорее всего где-то у вас возвращается не тот content- type, который имеет смысл для данного ресурса. Например для картинки возвращается text/html

Народ мне нужен ваш совет. Я собираюсь обработать ошибку регистрации в эндпоинте регистрации юзера при случае если email, под который ты хочешь завести аккаунт уже зареган и существует в БД. Но я это сделал и при этом послал заголовки ответа на запрос, указывая в одном из них значение инвалидного email-а, который фронт потом обрабатывает, но потом понял, что это может быть чертовски не безопасно. Вы согласны с этим ??? Если да, то как мне сделать так, чтобы более безопасным образом вернуть данные респонсом о том, что эмайл уже существует ??? Подойдёт ли для этого просто юзать код статуса 409 ибо он связан с конфликтами между переданными данными и состояние данных любого ресурса на сервере, в данном случае данные об записи пользователя в БД ???

Я просто не уверен в своих рассуждениях, поэтому и спрашиваю

Попробуй сделать это через валидатор.

В смысле, как вариант.