fix(i18n): detect duplicate allowlist entries, correct the collapse advice (#2221)

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

docs/i18n.md

@@ -214,10 +214,26 @@ Scoping inverts it. The guard can only ever tighten:
   is no treadmill.
 - Every migration PR moves one path from the second group to the first.
 
-Entries are globs, so use a file glob while a directory is partly migrated and
-collapse to `dir/**` once it is done. **Never remove an entry** to make a build
-pass — that silently un-protects migrated copy. `check-guard-allowlist.mjs`
-enforces this: it fails if an entry disappears while its path still exists.
+Entries are globs, so use a file glob while a directory is partly migrated. When
+it is done, leave those entries where they are: **adding a path is the only safe
+edit to this list.**
+
+`check-guard-allowlist.mjs` fails if an entry disappears while its path still
+exists — globs included, resolved with `fs.globSync`. So **never remove an entry**
+to make a build pass, and equally, never tidy several file globs into one
+`dir/**`. Both produce the same diff to the array, the check cannot tell them
+apart, and refusing to guess is the point: one of them silently un-protects
+migrated copy. A broader glob added *alongside* the existing entries passes;
+swapping them for it does not.
+
+The same check rejects a path listed **twice**. An exact duplicate changes no
+behaviour, so nothing else looks for one — the eslint rule is indifferent to a
+repeated pattern, and the removal check above only inspects entries that *left*
+the array. That is how #2214 landed two past every gate the repo then had. What a
+duplicate costs is the record: it claims an earlier migration's coverage as the
+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.
 
 ### …but new code is guarded everywhere