наконецто работает поиск верно

src/webparts/requestPortal/shared/pnp/pnpjs.ts

@@ -4,9 +4,18 @@ import '@pnp/sp/lists';
 import '@pnp/sp/items';
 import '@pnp/sp/attachments';
 import '@pnp/sp/site-users/web';
+import { BrowserFetchWithRetry } from '@pnp/queryable';
 import { WebPartContext } from '@microsoft/sp-webpart-base';
 import { DATA_SITE_URL } from '../config';
 
+// Мягкая ретрай-политика вместо стандартной PnPjs (retries: 3, interval: 200).
+// Дефолт слишком напорист: при отказе (429 «слишком много запросов», 503) он
+// начинает повторять почти сразу, что при массовой загрузке только усугубляет
+// throttling со стороны SharePoint. Здесь меньше попыток и заметно длиннее
+// первая пауза; интервал в PnPjs удваивается с каждой попыткой, так что выходит
+// примерно 1.5с → 3с.
+const RETRY = { retries: 2, interval: 1500 };
+
 // Единый инициализированный клиент PnPjs на весь web part.
 let _sp: SPFI | undefined;
 
@@ -16,7 +25,18 @@ let _sp: SPFI | undefined;
  * списки живут там, где бы ни стоял сам web part. Авторизация берётся из context.
  */
 export function initSP(context: WebPartContext): void {
-  _sp = spfi(DATA_SITE_URL).using(SPFx(context));
+  _sp = spfi(DATA_SITE_URL).using(SPFx(context), BrowserFetchWithRetry(RETRY));
+}
+
+/**
+ * Клиент для ПРОИЗВОЛЬНОГО сайта (списки типов заявок живут на разных сайтах,
+ * см. approval-route API). В отличие от getSP() не кэшируется — адрес сайта
+ * приходит из данных. Ретрай-политика та же, что и у основного клиента:
+ * BrowserFetchWithRetry идёт ПОСЛЕ SPFx, поэтому заменяет его обработчик
+ * отправки (у behavior replace: true по умолчанию).
+ */
+export function spForSite(siteUrl: string, context: WebPartContext): SPFI {
+  return spfi(siteUrl).using(SPFx(context), BrowserFetchWithRetry(RETRY));
 }
 
 /** Получить инициализированный клиент. Бросает, если initSP не был вызван. */