feat: add English frontend translation coverage

[RomuloGatto]

Summary

• Keep Simplified Chinese as the default language; English is only restored when explicitly selected via jellyfish_language=en-US.
• Move main layout navigation and breadcrumb labels into zh-CN/en-US translation resources.
• Add an English translation coverage layer for existing hardcoded frontend UI text so English mode renders current screens in English while the app migrates hardcoded labels to first-class i18n keys.
• Expand the English UI dictionary to cover extracted Chinese frontend UI literals, JSX text fragments, template literal fragments, and common runtime labels.
• Fix the interim DOM translator to prefer longer source phrases first so short keys cannot partially corrupt longer labels.
• Fix spaced Ant Design two-character button labels such as 取 消 by matching compact Chinese source phrases before translating.
• Fix Settings page namespace usage so it resolves real localized strings instead of displaying raw i18n keys.

Test Plan

• Static scan: no remaining uncovered Chinese JSX/template literal fragments outside locale/generated files.
• cd front && pnpm exec tsc --noEmit
• cd front && pnpm run build
• Browser verification on local Vite app:
  • default/no stored language renders Simplified Chinese on /projects
  • explicit English selection renders /projects, /agents, /models, /assets, /prompts, /files, and /settings with no Chinese text detected in document.body.innerText
  • verified the New Project modal renders the footer buttons as Cancel and Create and enter, with no Chinese text detected
  • verified /settings no longer displays raw settings.* keys.

[Forget-C]

Request changes

Thanks for pushing the English coverage work forward. I found a few blocking issues before this can merge:

1. The default language is now effectively en-US for first-time visitors, because both the i18n bootstrap and app store initialization fall back to English unless localStorage explicitly contains zh-CN. That conflicts with the PR description and our current product rule that Simplified Chinese remains the default unless English is explicitly selected.

2. The DOM compatibility translator appears to be one-way. In English mode it mutates hardcoded Chinese DOM text/attributes in place, but when switching back to zh-CN it stops translating and does not restore previously mutated nodes. For legacy labels that do not fully rerender on language change, the UI can remain partially English until a full reload.

3. This PR also changes multiple backend analysis agents to require English output for issues and optimized_description. That is a broader business-behavior change than frontend UI translation coverage and will affect Chinese-default prep/extraction workflows. Unless that is explicitly intended, documented, and reviewed as a separate product change, it feels out of scope and too risky to bundle into this PR.

I’d recommend keeping this PR focused on frontend translation coverage, preserving Chinese as the default language, and separating any backend output-language policy changes into a dedicated follow-up PR.