fix(language): make the parser setting real, and Chinese use jieba (#278)

[HugoFara]

Fixes #278.

The symptom, reproduced

A Chinese language created from the built-in preset parses a Chinese text to:

sentences=1  words=0

No clickable words at all — nothing to look up, nothing to track. That is the screenshot in the issue.

Three gaps stacked up to it

1. The parser setting was decorative. LgParserType was written by the language form and read by nothing. TextParsing::tokenize() branches only on the legacy MECAB magic word and otherwise goes straight to StandardTextParser. Measured — the value makes no difference at all, including a value that isn't a parser:

LgParserType	result
NULL	sentences=2 words=13
jieba	sentences=2 words=13
regex	sentences=2 words=13
mecab	sentences=2 words=13
totally-bogus	sentences=2 words=13

ParserRegistry had exactly two callers, both just filling the dropdown. CharacterParser, MecabParser and ExternalParser were unreachable from the parsing path.

2. External parsers never reached the dropdown either. ParserRegistry::__construct() takes an optional loader; both direct call sites passed none, so registerExternalParsers() returned immediately. jieba is installed in the published Docker image (Dockerfile:59-65 builds the venv and copies parsers/, matching config/parsers.php) and works — it was simply never listed.

3. The presets could not express a parser. langdefs.json has carried parserType for the CJK languages all along, but LanguagePresets::loadFromJson() flattened it into an eight-slot tuple that dropped the field. That is also why the Japanese preset, declaring mecab, silently resolved to character parsing even with MeCab installed.

What changed

• TextParsing consults the registry before the built-in pipeline and adapts Token → ParsedToken (the shapes differ only in sentence numbering and token ordering). The check-text preview uses the same parser as the save.
• ParserRegistry builds its own ExternalParserLoader when given none, so jieba and MeCab Python appear on an install that has them.
• LanguagePresets carries parserType as slot 8; the API exposes it; both preset appliers (the Alpine store and the wizard's DOM applier) set it.
• Chinese (Simplified) and (Traditional) ask for jieba, keeping makeCharacterWord so the fallback stays meaningful.
• The form gained an Automatic option, so "infer from the flags" stays expressible. New locale key across all nine languages.

Opting in is deliberate; the fallback is safe

Only an explicit, non-default LgParserType routes to the registry. The legacy signals resolveParserTypeFromRow() also understands — the MECAB magic word and LgSplitEachChar — are deliberately ignored there, so every language that exists today parses byte-identically; none of them stores a parser type.

A parser the server cannot run falls back to the built-in pipeline, never to the regex parser — which for a CJK language is precisely the zero-word text this issue is about.

Verified end to end, real database, jieba installed

preset (jieba)        LgParserType='jieba'     sentences=2 words=7
no parser type        LgParserType=NULL        sentences=2 words=13
unavailable parser    LgParserType='sudachi…'  sentences=2 words=13

7 is jieba word segmentation (我 | 喜欢 | 学习 | 中文 | 这是 | 一个 | 句子); 13 is one token per character.

Checks

Psalm 0 errors · PHPCS 0 errors, 0 warnings · PHPUnit 9101 pass (11 new, covering opt-in resolution, the legacy signals staying inert, the unavailable-parser fallback, and the preset slot) · Vitest 4326 pass · tsc and ESLint clean · assets rebuilt.

Not in this PR

• The "0 words" warning. Nothing tells you a language's rules match nothing in your text. Worth doing separately as the backstop for every other misconfiguration.
• The dead NLP /parse/ route. services/nlp/ has a second, complete jieba — JiebaParser, a live endpoint, and a PHP client in NlpServiceHandler::parse() / getAvailableParsers(). Both have zero callers. Two implementations, one a decoy; worth either wiring up or deleting.