feat(tray): 添加系统托盘多语言支持

[taojianhang]

实现系统托盘菜单和提示的多语言切换功能，包括：

1. 新增 tray:updateLanguage IPC 接口用于更新语言
2. 重构托盘模块以支持动态语言切换
3. 在设置变更时同步更新托盘语言
4. 添加中英日三语的托盘菜单翻译

[hazeone]

1. High — persisted non-English users will still get an English tray after restart.
   The tray is created in main-process startup, while persisted settings are loaded later from the renderer. In this PR, tray translation sync is only triggered from setLanguage() during an in-session language change; it is not triggered during settings init(), and main-side settings mutations/reset paths also have no tray hook. That means existing users who already have zh/ja saved will not see the localized tray on launch until they manually toggle language again. This is a backward-compat regression for existing installs, and a forward-compat risk for any future/non-renderer settings writes.index.ts:148-169 App.tsx:89-112 settings.ts:96-117 settings.ts:37-90 86f48db8-17c1-458f-b59f-3c4154721eef.txt:473-516

2. Medium — tray status semantics are reduced from full lifecycle states to a binary running/stopped view.
   GatewayManager exposes stopped, starting, running, error, and reconnecting. Today the tray tooltip preserves the raw status string. In the PR, index.ts forwards raw status.state into updateTrayStatus(), but the new tray implementation only treats 'running' specially and maps every other state to the stopped translation/menu. That hides startup, reconnect, and error states, and it is not forward-compatible with any future lifecycle state additions.manager.ts:48-57 tray.ts:163-169 86f48db8-17c1-458f-b59f-3c4154721eef.txt:28-49 86f48db8-17c1-458f-b59f-3c4154721eef.txt:345-376

3. Medium — the new IPC path is brittle under renderer/main/preload version skew.
   The PR fires void syncTrayTranslations() with no error handling. If the renderer bundle gets ahead of preload/main during dev hot reload, partial rollout, or a test harness with an older preload mock, preload explicitly throws on unknown IPC channels and invokeIpc() propagates that failure. Packaged releases usually update atomically, but this is still a backward/forward compatibility risk at the process-boundary level.86f48db8-17c1-458f-b59f-3c4154721eef.txt:490-516 index.ts:142-146 api-client.ts:315-343

Residual platform risk

I do not see a new icon-format/path regression in the diff; tray icon selection stays platform-specific for Windows/macOS/Linux. The main platform concern is validation coverage: CI only runs Ubuntu lint/type/test and a Windows frontend build, so macOS tray/menu runtime behavior remains unverified even though the tray code has macOS-specific behavior.tray.ts:23-55 check.yml:10-62

Bottom line

I would block on finding 1. Findings 2 and 3 are medium-risk compatibility issues that I would want resolved or explicitly accepted before merge.