feat(i18n): localize Automations (#2247)

Co-authored-by: Kandev Agent <agent@kandev.dev>

docs/i18n.md

@@ -235,6 +235,30 @@ new PR's. Entries that a broader glob already covers are deliberate and stay —
 they record which PR migrated which half of a group — so this is an exact-match
 check, not a redundancy check.
 
+#### An entry can be born dead, and only a glob expansion shows it
+
+Both checks above ask what happened to an entry *between* two states. Neither
+asks the prior question: **does this entry match any file at all?** An entry that
+matched nothing on the day it was added is indistinguishable from a healthy one —
+it never leaves the array, it is never a duplicate, and `pnpm lint` passes
+because the rule simply has no files to apply to. The list grows, the ratchet
+reports "N added", and the path is unguarded.
+
+A dynamic route is the way to hit this, because Next-style directories are named
+in glob syntax. `[id]` is a **character class** matching a single `i` or `d`:
+
+```bash
+node -e 'console.log(require("fs").globSync("app/settings/workspace/[id]/automations/**/*.tsx").length)'   # 0
+node -e 'console.log(require("fs").globSync("app/settings/workspace/[[]id[]]/automations/**/*.tsx").length)' # 4
+```
+
+The Automations migration (#2247) shipped the unescaped form, and review caught
+it. So when an entry contains `[`, escape it as `[[]…[]]` — and prove the entry
+is live rather than trusting the glob result, the same way you would prove any
+other check earned its pass: put a hardcoded literal in one of the files the
+entry is supposed to cover and confirm `pnpm lint` reports
+`i18next/no-literal-string`, then remove it. A silent 0 errors is the tell.
+
 ### …but new code is guarded everywhere
 
 Scoping the whole-file guard leaves a hole: a brand-new component under an