Deduplicate overlapping rules across contracts

Each rule now has one owning contract; others point to it:
validation and multi-step rules live in forms-validation (modal-workflows
references them), pagination metadata lives in go-api (table-management
references it), the async task flow lives in go-background-tasks (go-api
references it), backup git-safety checks live in backup-management
(go-database references it). Remove the leftover Vapor/Aqua baseline
mention and stale kit/patterns paths, compress the batch-file-upload ADR
narrative, and drop content-free pattern READMEs.

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

rules/patterns/batch-file-upload/contract.md

@@ -1,30 +1,16 @@
 # Contract: Batch File Upload
 
-Version: 1.0
+Version: 1.1
 
 ## Purpose
 
-ADR: стратегия загрузки большого числа файлов через multipart-запросы
-без переработки серверного pipeline и без скрытых лимитов.
+Загрузка большого числа файлов одним multipart-запросом упирается в скрытые лимиты:
+количество parts, размер тела запроса (413), таймауты соединения. Поэтому клиент делит
+список файлов на батчи фиксированного размера и отправляет каждый батч отдельным
+multipart-запросом. Цена решения — больше round-trips и, без агрегации, несколько
+выходных файлов.
 
----
-
-## ADR
-
-**Дата:** 2026-03-01
-**Статус:** Accepted
-
-### Контекст
-
-Клиент должен загрузить список файлов на сервер для обработки.
-Загрузка всех файлов одним multipart-запросом упирается в скрытые лимиты:
-количество parts, размер тела запроса (413), таймауты соединения.
-Переработка серверного pipeline под стриминговую загрузку — отдельная дорогостоящая задача.
-
-### Решение
-
-Клиент делит список файлов на батчи фиксированного размера и отправляет каждый батч
-отдельным multipart-запросом.
+## Решение
 
 - Размер батча определяется константой `MAX_FILES_PER_BATCH` (выбирается проектом).
 - Батчи считаются по **числу файлов**, не только по байтам.
@@ -33,18 +19,6 @@ ADR: стратегия загрузки большого числа файло
 - Каждый батч производит отдельный downloadable артефакт,
   либо агрегируется на финальном шаге — решение принимается на уровне проекта.
 
-### Последствия
-
-**Плюсы:**
-- Избегаем скрытых лимитов на количество multipart parts
-- Снижаем риск таймаутов и ошибок 413
-- Не требует немедленной переработки серверного parser pipeline
-
-**Минусы:**
-- Больше round-trips (N батчей = N запросов)
-- Несколько выходных файлов если артефакты не агрегируются
-- Более долгий end-to-end UX для пользователя
-
 ---
 
 ## Правила реализации