docs(git): tighten commit message rules for all projects

- replace IaC-specific wording with general, cross-project guidance
- forbid runtime/incident/manual-ops narrative in commit message body
- clarify commit messages describe repo changes, not behavior outcomes

.ai/instructions/skills/git.instructions.md

@@ -36,7 +36,7 @@ Otherwise: **SHOW the command, WAIT for user to run it**
 - Explain impact of each git operation
 - User controls git commands, you analyze and advise
 - Never assume user wants to commit
-- Production platform infrastructure: Stability > Speed
+- Reliability over speed
 
 ---
 
@@ -76,3 +76,13 @@ Types: `feat`, `fix`, `docs`, `refactor`, `chore`
 - Bullet points state *what* changed, not *why it was wrong* or *how it works* — keep each line short and factual
   - ✅ `use MC_HOST_minio for S3 auth`
   - ❌ `Use MC_HOST_minio env var for direct S3 auth (no mc alias set)`
+- Do not describe runtime behavior, incident narrative, or manual operations in the commit message body
+  - ❌ `gitea failed on startup`
+  - ❌ `Redis services cleaned up manually`
+  - ❌ `Certificate renewed successfully`
+  - ✅ `disable redis sub-chart`
+  - ✅ `set queue type to level`
+
+**All projects:**
+- Treat commit messages as change logs of repository state, not behavior reports
+- Never include runtime status, deployment outcomes, test run narratives, or manual operation confirmations unless the user explicitly asks for a release note or status report instead of a commit message