react-yandex-maps отличная бибилиотека, использовал на 2-х проектах, проблем вообще никаких нет, в том числе и с яндекс картами самими.

Сам же ключ при использовании react-yandex-maps нужно вписывать в query у YMaps Provider:

<YMaps
  query={{
    ns: "use-load-option",
    apikey: "ваш ключ api",
    load: "загружаемые модули"
  }}
>

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

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

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

Например, я решал такую задачу следующим способом:
1. Создал объект правил доступа для различных компонентов/страниц.

const rules = {
  articles: {
    create: 'articles:create',
    edit: 'articles:edit'
  }
}

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

2. Затем создал объект с уровнями доступа и доступными им правилами, для каждой роли это просто Set в который загоняются доступные действия из правил.

3. Ну и функция, которая на вход принимает правило и по текущей роли пользователя ищет в Set коллекции это самое правило, нашли - значит доступно, вернули true

Далее в нужном компоненте дергаем нашу функцию проверки прав, передавая туда правило для проверки доступа. Например, у нас просто обычный юзер залогинился, а не редактор.
Вызываем checkPermission(rules.articles.edit), если функа вернула false, то блокируем или скрываем кнопку редактирования статьи, ну и т.д.

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

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

Чтобы все названия месяцев при использовании date-fns были в именительном падеже необходимо убрать из локали форматированные названия месяцев (т.е. formattingMonthValues).

Для этого либо:
1. Создаем отдельный файл с локалью, копируем в него все из имеющейся в date-fns ru локали. С помощью buildLocalizeFn перезаписываем месяцы и импортируем везде, где нужно этот файл вместо локали из date-fns/locale/ru.

Код для измененной ru локали без форматированных месяцев:

import formatDistance from "date-fns/locale/ru/_lib/formatDistance";
import formatRelative from "date-fns/locale/ru/_lib/formatRelative";
import localize from "date-fns/locale/ru/_lib/localize";
import match from "date-fns/locale/ru/_lib/match";
import formatLong from "date-fns/locale/ru/_lib/formatLong";
import buildLocalizeFn from 'date-fns/locale/_lib/buildLocalizeFn'

const monthValues = {
  narrow: ["Я", "Ф", "М", "А", "М", "И", "И", "А", "С", "О", "Н", "Д"],
  abbreviated: [
    "янв.",
    "фев.",
    "март",
    "апр.",
    "май",
    "июнь",
    "июль",
    "авг.",
    "сент.",
    "окт.",
    "нояб.",
    "дек."
  ],
  wide: [
    "январь",
    "февраль",
    "март",
    "апрель",
    "май",
    "июнь",
    "июль",
    "август",
    "сентябрь",
    "октябрь",
    "ноябрь",
    "декабрь"
  ]
};

const ruLocale = {
  formatDistance,
  formatLong,
  formatRelative,
  localize: {
    ...localize,
    month: buildLocalizeFn({
      values: monthValues,
      defaultWidth: "wide",
      defaultFormattingWidth: "wide"
    })
  },
  match,
  options: {
    weekStartsOn: 1,
    firstWeekContainsDate: 1
  }
};

export default ruLocale;

2. Перезаписываем нужные месяцы в имеющейся локали напрямую после импорта

import ru from "date-fns/locale/ru";
import buildLocalizeFn from 'date-fns/locale/_lib/buildLocalizeFn'
  
  const monthValues = {
    narrow: ["Я", "Ф", "М", "А", "М", "И", "И", "А", "С", "О", "Н", "Д"],
    abbreviated: [
      "янв.",
      "фев.",
      "март",
      "апр.",
      "май",
      "июнь",
      "июль",
      "авг.",
      "сент.",
      "окт.",
      "нояб.",
      "дек."
    ],
    wide: [
      "январь",
      "февраль",
      "март",
      "апрель",
      "май",
      "июнь",
      "июль",
      "август",
      "сентябрь",
      "октябрь",
      "ноябрь",
      "декабрь"
    ]
  };

  ru.localize.month = buildLocalizeFn({
    values: monthValues,
    defaultWidth: 'wide',
    defaultFormattingWidth: 'wide'
  })

usersList.forEach(user => console.log(user.company.name))

Потому что кое что забыли в addMatcher. Сейчас у вас оба слайса в extraReducers матчатся на все асинхронно возвращаемые через промисы экшены, поэтому данные и записываются в оба слайса Т.е. вам необходимо матчить по название thunk + статус, а не только по статусу, как пример, для option:
вот вы создали async thunk с типом "countries/fetchCountries"

export const fetchCountries = createAsyncThunk(
  'countries/fetchCountries',
...

и в addMatcher будет тогда:

(action) => action.type.endsWith("countries/fetchCountries/pending"),

Ну и везде так поменяйте.