i18n: no language/script validation replaced lobe-i18n's ELD lint

## Problem

`@lobehub/i18n-cli` shipped a `lint` command backed by ELD language detection
(`@yutengjing/eld`), which flags translated files whose detected language does not match
their locale tag. Upstream spent several releases refining it — 1.24.0 extended the
language-similarity sets, 1.25.0/1.25.1 fixed the East-Asian grouping to include `zh`.

We never wired it into `package.json`, and
https://github.com/Comfy-Org/ComfyUI_frontend/pull/15062 removed the dependency, so the
capability is gone. Nothing in the current pipeline validates that a translated string is
actually in the target language or script.

## Why it matters here specifically

This is the one bug class the corpus has already shipped. `scripts/i18n/config.ts`
carries three separate prose warnings about it:

```
Use ONLY Simplified Chinese characters (简体中文) … NEVER mix Simplified and Traditional
Use ONLY Traditional Chinese characters (繁體中文) with Taiwan-specific terminology
```

Prose in a system prompt is not a check. #5013 ("Complete traditional to simplified
Chinese character conversion") exists because this already went wrong once, and `zh` and
`zh-TW` are generated by the same model from the same English with only a guidance string
distinguishing them.

A related live example: `g.searchPlaceholder` in `zh` is `搜索占位符` — literally "search
placeholder", a translation of the key name rather than the value. Language detection
would not catch that one, but a script check would catch the Simplified/Traditional class,
which is the one that affects whole files rather than single keys.

## Suggested fix

`eld` is a standalone package. A `pnpm locale:lint` that runs detection per locale file
and a script-range check for `zh` vs `zh-TW` would restore the guard at a fraction of the
dependency we removed. It fits naturally next to `pnpm locale:check` in
`.github/actions/lint-format-verify`.