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/forms-validation/README.md

@@ -1,12 +0,0 @@
-# Forms + Validation Pattern
-
-Canonical patterns for server-rendered form workflows in Go web applications:
-
-- tabbed / mode-switched forms
-- datalist/autocomplete suggestions
-- inline validation messages
-- review / confirm step before submit
-- explicit reset and error handling states
-
-This pattern standardizes interaction flow and validation UX, not domain-specific field sets.
-

rules/patterns/forms-validation/contract.md

@@ -1,6 +1,9 @@
 # Contract: Forms + Validation + Suggestions
 
-Version: 1.0
+Version: 1.1
+
+This contract owns validation UX and multi-step flow rules for all form surfaces,
+including modals (`modal-workflows` adds only modal-specific mechanics).
 
 ## Form Structure
 
@@ -10,8 +13,10 @@ Version: 1.0
 
 ## Validation
 
+- Validate on submit server-side. Client-side validation is optional progressive enhancement only.
 - Surface validation errors inline near fields and in a form-level summary when helpful.
-- Validation messages must be human-readable and action-oriented.
+- Validation messages must be human-readable and action-oriented: "Serial number is required" —
+  not "serial_number: cannot be null".
 - Do not hide required-field errors behind generic submit failures.
 
 ## Multi-Step Flow
@@ -26,6 +31,7 @@ Recommended stages:
 Rules:
 
 - Users must be able to return from review to edit without losing entered values.
+- The confirm step must summarise what will happen before a destructive or irreversible action.
 - Destructive or irreversible actions require explicit confirmation.
 - Query- or state-driven step transitions should be deterministic and testable.