Почистить комментарии от упоминаний процесса

Удалены <remarks>, <summary> сжаты до короткой фразы, вырезаны
ссылки на Task/Ruling/этап/python/прототип; //-комментарии со ссылками
на процесс удалены; то же в .proto. Правила обновлены в
docs/spec/Код-стайл-Дейл.md. Строк комментариев 27210 -> ~19100.

docs/spec/Код-стайл-Дейл.md

@@ -112,6 +112,15 @@
   там, где неочевидна причина/ограничение (короткий обычный комментарий).
 - **Кратко.** Комментарий объясняет **зачем и что**, а не пересказывает код. Не дублировать имя и
   сигнатуру словами.
+- **`<summary>` — короткое описание (одна фраза).** Это назначение типа/члена, а **не** «как оно
+  работает» и не пояснения/детали реализации. Несколько предложений в summary не пишем.
+- **`<remarks>` не используем** — подробные пояснения «как устроено» не нужны; rationale — только если
+  поведение действительно неочевидно, коротким обычным комментарием.
+- **Никаких упоминаний процесса:** в комментариях запрещены ссылки на таски/этапы/рулинги/планы и
+  прототип (`Task N`, `Ruling N`, `этап N`, `python L…`, `main.py`, `прототип`, `LEADRADAR_*` и т.п.).
+- **Внутренние `//`-комментарии — только для неочевидного поведения** (причина, ограничение, подвох).
+  Пересказ кода, пошаговая навигация и «что делает следующая строка» — удалять.
+- **`<param>`/`<returns>`** — только если смысл не очевиден из имени/типа; не переписывать сигнатуру.
 - **`<summary>` — только блочный.** Открывающий `<summary>` и закрывающий `</summary>` — **каждый на
   своей строке**; запись в одну строку (`/// <summary>текст</summary>`) **не допускается**. **[изм.]**