fix(#605): declare the ICU parser, correct the i18n docs, pin test concurrency

[Weegy]

Closes #605

Three independent hygiene items left over from PR #599. Items 4 (store "Jetzt installieren" vs. admin "VERBUNDEN") and 5 (/setup 403 gate relaxation) of the issue are product / sign-off decisions rather than code, so they are deliberately untouched here and the issue should stay open for them if this merges — see the note at the bottom.

1. @formatjs/icu-messageformat-parser was undeclared

The t.rich CI guard in web-ui/app/_lib/i18n-parity.test.ts imports it, but it resolved only transitively via next-intl → intl-messageformat. Declared as a devDependency at ^3.5.16 — the version already in the tree — so the lockfile gains nothing but the declaration.

No test can cover this one: the package is present either way today, which is exactly why the issue calls it a latent hoisting hazard rather than a live bug.

2. web-ui/CLAUDE.md pointed at the wrong gate

The checklist said npm run i18n:check fails on mismatched ICU/tag placeholders. It does not. i18n:check runs only scripts/i18n-validate.mjs, which covers key sets, empty/non-string values, forbidden HTML, and de === en warnings.

The placeholder and rich-text-tag parity check is real and is enforced in CI — it just lives in the vitest guard, not in i18n:check. Verified by running npm run i18n:check on this branch: it reports OK — 3565 keys plus de === en warnings and says nothing about placeholders.

The checklist now names both commands and what each actually catches. This matters because the routines crash that motivated #599 was precisely a placeholder mismatch that passed i18n:check with all keys present — trusting the wrong gate is the documented failure mode.

3. test now pins --test-concurrency=4

Node derives the default from the core count. This machine reports availableParallelism = 16, so it ran 16 files at once; a 4-vCPU CI runner runs ~4. The suite starts many short-lived Express servers on localhost, and the issue records three consecutive full runs each failing a different test (runtimeSecretsRoute, conductorTemplateRoutes, inboundWebhookRoutes), two with a connection-level fetch failed, every one passing in isolation.

Since package.json cannot carry a comment, the rationale sits in the CI comment next to the step, matching how test:pg's --test-concurrency=1 is already documented.

Measured cost, on a 16-core machine

Run	Wall clock	CPU	Result
unpinned (default 16)	36.5 s	747 %	6174 tests, 0 fail
pinned =4	48.0 s	424 %	6174 tests, 0 fail

+31 % locally. On a 4-vCPU runner the default is already ~4, so the pin is close to a no-op for CI wall clock — the cost lands on large dev machines only.

Corrected after further measurement (see #666). My first pass here said the flake had not reproduced. It does. On the #566 branch I hit a full 120 000 ms file timeout on test/devplatform/devPlatformRoutes.test.ts at the default concurrency of 16 — that file runs in 1.77 s and 29/29 green in isolation.

I then ran a controlled A/B, same commit, 3 rounds each at --test-concurrency=4: 1 green / 2 red in both arms. So the pin reduces the flake — it turns a whole-file hang into an occasional single-test ECONNREFUSED — but it does not make the suite deterministic on a 16-core machine. The issue's "fully green at 4" was a single run, and so was mine.

Victims seen across runs: builderIssueReporting, devPlatformGates, devWebhooks, devPlatformRoutes — all connection-level (ECONNREFUSED / fetch failed), which supports the localhost socket-contention theory in the issue.

CI's 4-vCPU runner is consistently green today, so this does not currently bite there. Read this change as capping the blast radius on large dev machines, not as closing the flake. The contended resource still deserves the hunt the issue proposes as its other option; this change is trivially revertible if you would rather do that first.

Verification

• web-ui: i18n:check OK (3565 keys) · vitest 673 tests / 80 files, all pass · lint 0 errors · typecheck clean
• middleware: build OK · 6174 tests, 0 fail, 4 skipped with the pin in place
• Branch is on current main (3c86f1c8)

Note for the reviewer

Closes #605 will auto-close the issue on merge, but items 4 and 5 are still open questions. If you want them tracked, either reopen after merge or drop the Closes line and close manually — happy to split them into their own issue instead.