Дмитрий Гординский

Пару лет назад столкнулся с похожей задачей, сидинг данных через миграции регулярно стрелял в ноги, и нужно было его вынести в отдельный функционал. Так и не понял почему DoctrineFixturesBundle продвигается как тула именно для тестирования, видимо неудачный нейминг оригинальной либы сыграл своё.
В доке к оригинальной либе среди юзкейсов упоминается в том числе и сидинг вне контекста тестов.
Doctrine Data Fixtures

Но, проверять на живом проекте я так и не решился и набросал на коленке свой силдер с нужным мне функционалом из 2-3 классов.

Как при загрузке фикстур для свойств класса (ManyToOne) указать уже имеющиеся в БД данные?

Если используются кодогенирируемые уникальные идентификаторы - можно их прописывать в константы, и использовать при сидинге родительской сущности, а потом её же использовать при сидинге потомков.
Если таких нет - хранить в константах те поля по которым оригинальную сущность получится найти и получить идентификатор.

Assert\Optional говорит лишь о том что поле может отсутствовать, но если оно присутствует, оно должно соответствовать описанным правилам.

То есть правило из вопроса подразумевает что валидируемые данные могут вовсе не содержать ключа financialpersoninn, и при этом будут считаться валидными. Если же такой ключ присутствует, его значение должно удовлетворять заданным правилам.

Как вариант можно использовать композитные правила AtLeastOneOf.

Стоило бы посмотреть как sql запрос в итоге формируется и где происходит несоответствие форматов.

При передаче в качестве параметра запроса можно явно сконвертировать Ulid в нужный формат:
$entity->getUlid()->toBase32()

Нужна не наугад с опциями играться, а сравнивать ответ из Symfony-клинета с тем HTML который получается успешно обработать.

Поднять докер локально и запускать composer в нём.

Массив $toSave не очищается после обработки батча.

$_POST

Убедится в корректности конфигурирования роутов можно командой:
php bin/console debug:router

Дока

Разбить по отдельным сервисам*, в том числе и содержимое commonMethod вынести в отдельную структуру, которую использовать в сервисах с methodFirst и methodSecond.

*это не обязательно должны быть сервисы

Написать кастомный обработчик ошибки

Дело не в абстрактном классе. Symfony требует явной регистрации реализаций интерфейсов.

Выглядеть это будет примерно так:

services:
  ...
  App/Interfaces/UserRepositoryInterface:
    alias: App/Repositories/UserRepository

Дока

В том же мануале даже названия файлов приведены.

Создать слушателя для ивента ResponseEvent, и уже в нём проверять статус, и отправлять ошибку на дальнейшую обработку