feat: i18n / localization support for TUI strings instead of hardcoded English

Problem

All TUI interface strings in jcode are hardcoded as English &'static str literals directly in Rust source code. This includes:

• Header labels: model name, provider, status indicators
• Picker column headers: MODEL, PROVIDER, METHOD, ACCOUNT, STATE, TARGET, CONFIG, ITEM, STATUS, WINDOW
• Status messages: "Thinking...", "Streaming", "Sending...", "Idle", "Running tool: ..."
• Onboarding screens: welcome text, login prompts, suggestion cards
• Keybinding hints: "↵ open", "↵ select", "↑↓ ←→ ↵ Esc"
• Tool display labels: format strings for tool calls, batch progress, caching warnings
• Many more across ~30 UI files (30K+ lines) in crates/jcode-tui/src/tui/

There is no locale detection, no translation system, and no config option to switch the UI language. This makes jcode less accessible to non-English-speaking users.

Suggested Solution

Add an optional i18n layer to the TUI so that UI strings can be localized without modifying source code:

Approach (fluent-rs)

Use the fluent-rs ecosystem (the Rust implementation of Mozilla's Fluent localization system), which is well-suited for a Rust TUI:

1. Add fluent-rs / unic-langid dependencies to jcode-config-types (for the config field) and jcode-tui (for string resolution)
2. Add language = "..." field to [display] in config.toml (default: "en-US")
3. Extract hardcoded strings into .ftl (Fluent) files under e.g. locales/en-US/tui.ftl and locales/zh-CN/tui.ftl
4. Replace "LABEL" with t!("label") calls throughout jcode-tui/src/tui/
5. Bundle locale files at compile time via include_str! or fluent-template, so no runtime file discovery is needed

Minimal first step

A minimal PR could:

• Add the config field and fluent-bundle dependency
• Extract just the most visible strings (~50-100 labels: column headers, status lines, onboarding text, keybinding hints)
• Ship en-US.ftl (identical to current hardcoded text) and zh-CN.ftl
• Leave the remaining strings for follow-up PRs

This gives an incremental path: every new feature adds its strings to the .ftl file instead of hardcoding, and over time the entire TUI becomes localizable.

Alternative: rust-i18n crate

rust-i18n is a simpler macro-based approach with automatic extraction. It uses YAML files and a t!() macro. Less powerful than Fluent but easier to get started with.

Why a plugin won't work

jcode has no plugin/dynamic-loading system (no WASM, no dlopen, no libloading). An i18n solution must therefore be built into the core codebase rather than shipped as an external plugin.

Benefits

• Enables community-contributed translations (Chinese, Japanese, Korean, etc.)
• Makes jcode more accessible globally
• Separates UI text from logic (better engineering practice)
• Opens the door for right-to-left (RTL) language support later

Issue inspired by a user who wanted to use jcode with a Chinese-language TUI.

Start by reading the configuration types in jcode-config-types and the UI entry points under crates/jcode-tui/src/tui/. Inventory the highest-visibility strings named in the issue and compare Fluent with the rust-i18n alternative before choosing an approach. Done should include a language config field, bundled en-US and zh-CN resources, and localized labels, status lines, onboarding text, and keybinding hints.