问题描述
----------
使用 facebook/nllb-200-distilled-600M（CTranslate2 后端）时，若 API 传入 ISO 639-1
或 FLORES 短标签（如 ca、da、nl、sv、no、tr 等），会触发
「Unsupported NLLB source/target language」。模型与 tokenizer 实际支持这些语言；
根因是 resolve_nllb_language_code 仅依赖 translation/languages.py 里十余条
NLLB_LANGUAGE_CODES 映射，大量合法短码未注册，校验误报为不支持。

修改内容
----------
1. 新增 translation/nllb_flores_short_map.py
   - NLLB_FLORES_SHORT_TO_CODE：与 HF 模型卡 language 列表对齐的短标签 ->
     NLLB 强制 BOS/src_lang 形式（<ISO639-3>_<ISO15924>，如 cat_Latn）。
   - NLLB_TOKENIZER_LANGUAGE_CODES：从 tokenizer.json 提取的 202 个语言 token
     全集，供直接传入 deu_Latn 等形式时做规范化解析。
   - 额外约定：ISO 639-1「no」映射 nob_Latn（书面挪威语 Bokmål）；nb/nn 分别
     对应 nob_Latn / nno_Latn；「ar」显式指向 arb_Arab（与 NLLB 一致）。

2. 调整 translation/languages.py
   - build_nllb_language_catalog：合并顺序为 FLORES 全表 -> NLLB_LANGUAGE_CODES
    （保留少量显式覆盖，如 zh->zho_Hans）-> 调用方 overrides。
   - resolve_nllb_language_code：在目录与别名之后，增加基于
     NLLB_TOKENIZER_LANGUAGE_CODES 的大小写不敏感匹配（如 eng_latn -> eng_Latn），
     覆盖「已传完整 NLLB 码」的场景。

3. tests/test_translation_local_backends.py
   - 新增 test_nllb_resolves_flores_short_tags_and_iso_no，覆盖用户关心的短码及
     deu_Latn 直通解析。

方案说明
----------
NLLB 接口语义以 Hugging Face NllbTokenizer 为准：语言标识为 FLORES-200 风格
三字母语种码 + 下划线 + 四字母脚本子标签（ISO 15924）。业务侧常用 ISO 639-1
（de、sv）或模型卡短列表（ca、nl），需在服务内统一映射到 tokenizer 特殊 token。
本实现以模型卡 language 字段 + tokenizer 词表为单一事实来源生成静态表，
避免运行时依赖额外库；同时保留原有 NLLB_LANGUAGE_CODES 作为薄覆盖层以兼容
既有配置与测试。

Refs: https://huggingface.co/facebook/nllb-200-distilled-600M
Made-with: Cursor