docs: корневая причина, почему managed properties не отдаются

Одноимённые колонки в РАЗНЫХ списках — разные поля со своими GUID, значит и со
своими crawled property (ows_Position, ows_Position1, …); автосозданное managed
property привязано только к одному из них. Отсюда PositionOWSTEXT, который
отдаёт значения в «Заявка на подбор — данные» и молчит в «Прием на работу —
данные» при одном и том же имени.

Проверять надо не «работает ли свойство», а «работает ли оно для ЭТОГО списка» —
этим занимается новая команда `sp-write props`.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

backend/Tnsu.ApprovalRoute.Application/Reports/VacancyReportService.cs

@@ -31,6 +31,15 @@ namespace Tnsu.ApprovalRoute.Application.Reports;
 /// Префикс группы колонок сайта (TansuSite…, см. tools/sp/README.md) тоже не
 /// помогает — пробовали.
 ///
+/// Причина, если понадобится чинить: одноимённые колонки в РАЗНЫХ списках — это
+/// разные поля со своими GUID, а значит и со своими crawled property
+/// (ows_Position, ows_Position1, …); автосозданное managed property привязано
+/// только к одному из них. Поэтому, например, PositionOWSTEXT отдаёт значения в
+/// «Заявка на подбор — данные» и молчит в «Прием на работу — данные». Проверять
+/// надо не «работает ли свойство», а «работает ли оно для ЭТОГО списка» — этим
+/// занимается `sp-write props` (репозиторий C:\work\git\tools), он же говорит,
+/// нужно ли домапить crawled property или свойства нет вовсе.
+///
 /// Значит эти поля пришлось бы дочитывать построчно батчами по 100 — и на 1000
 /// заявок Search+дочитка выходит ~46 HTTP-запросов против ~5 у нынешнего REST.
 /// В list view threshold (5000) REST при этом не упирается by design: партиции