Обычно я, при необходимости заполнить БД, использую миграции, где пишу запросы на чистом SQL. Не стоит вызывать EntityManager и тем более протаскивать контейнер целиком в миграции, как писали выше - это плохая практика.
Фикстуры, как здесь уже написали, - тестовая история, хотя никто вам не запрещает их использовать.

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

Security прекрасно может быть использован в REST, потому что он, по сути, просто предоставляет вам middleware для аутентификации пользователя, запускающееся при каждом запросе к вашему API. Саму же реализацию вы можете как выбрать из готовых, так и написать собственную. А UserProvider в свою очередь предоставляет вам доступ к объекту текущего пользователя внутри вашего кода, что весьма удобно.

Действительно, JWT достаточно, и никто не запрещает вам сделать реализацию без компонента security, однако его использование будет существенно удобнее при использовании этого бандла, который взаимодействует с security. В случае с ним вам не нужно будет даже писать реализацию middleware.

Можно сделать интерфейс для фильтров и реализовывать его для каждого конкретного фильтра. В нем будут методы для получения алиаса (для того, чтобы превратить массив фильтров из запроса в массив классов), установления значения фильтра, а также добавления условия в queryBuilder. Получая из запроса массив фильтров, собираем массив классов, реализующих этот интерфейс (можно, кстати, сделать коллекцию, но это по желанию) и в репозитории проходимся по нему циклом и для каждого элемента вызываем метод, который добавляет условия к текущему queryBuilder'у.