feat(i18n): add Turkish (tr) translation

[Ohualtex]

Summary

Adds a complete Turkish (tr) translation for the Odysseus UI as static/locales/tr.json. All 409 keys from static/locales/en.json are translated 1:1, covering navigation, brain, chat, settings, visibility, theme, sort, and common UI strings. Follows the structure established in PR #2383 (same approach as the German locale PR #4502), so it drops in once that framework lands.

Target branch

• This PR targets dev, not main.

Linked Issue

Part of #58 (i18n umbrella — partial: Turkish locale). I previously volunteered a Turkish locale on #58.

Type of Change

• New feature (non-breaking — adds new behaviour)

Checklist

• I searched open issues and open PRs — this is not a duplicate (no existing Turkish/tr locale PR).
• This PR targets dev
• My changes are limited to the scope described above — a single new locale file, nothing else touched.
• I actually ran the app end-to-end — not yet: this locale depends on the i18n framework in feat(i18n): add multilingual support with dynamic text mapping #2383, which is not merged. Instead I verified valid JSON, 1:1 key parity with en.json (409/409, no missing/extra keys), and that all {count} placeholders and code/paths (e.g. Ctrl+K, SKILL.md, 语言) are preserved.

How to Test

Data-only locale file; it activates once the #2383 i18n framework merges (same dependency as the German locale PR #4502).

1. Apply on top of feat(i18n): add multilingual support with dynamic text mapping #2383 (which adds static/js/i18n.js + the Settings language selector).
2. Open Settings → Language and choose Turkish.
3. Confirm nav, settings, chat, and common strings render in Turkish, falling back to English for any unset key.

Static checks already run locally: python3 -c "import json; json.load(open('static/locales/tr.json'))" (valid JSON) and a key-path diff against en.json (409/409, zero missing/extra).

Visual / UI changes

Data-only locale file — no CSS/HTML/SVG/styling changes, no new component patterns, no emoji; translated text only. In-app screenshots aren't possible until the #2383 framework merges.

[vdmkenny]

Holding this rather than reviewing it standalone, since it can't land or be validated yet:

• The i18n framework it depends on (feat(i18n): add multilingual support with dynamic text mapping #2383) is still open, so there's no loader to consume static/locales/tr.json and static/locales/en.json doesn't exist in dev. Without en.json there's nothing to validate the "409 keys 1:1" claim against, and if feat(i18n): add multilingual support with dynamic text mapping #2383's key structure changes during review the translations will drift.
• There's a parallel German locale PR (feat(i18n): add German (de) translation #4502) in the same blocked state.

The translation work is wanted (this is part of the i18n effort in #58), so please keep it open but coordinate on the main issue #58 (and #2383): the per-language PRs should land after the framework, re-synced against the final en.json so the keys line up. Once #2383 merges and en.json is in dev, rebase this, confirm the key set matches, and ping for review.

[Ohualtex]

Thanks @vdmkenny, that makes sense. Agreed on landing locales after the framework. I'll keep #4697 open and, once #2383 merges and en.json is in dev, rebase against the final en.json, confirm the key set matches 1:1, and ping you for review. Happy to help test/review #2383 if that helps it land.

[Ohualtex]

Closing this for now. A locale file can't function on its own — it needs the client-side i18n framework to load static/locales/*.json, and the framework PR this was built against, #2383, was closed by its author on 2026-06-25 (after #2676 before it). With no framework in dev, there's no loader to consume tr.json and no en.json to validate it against.

The translation isn't lost — it's a complete 409-key Turkish catalog, ready to re-submit (re-keyed if needed) once a framework and its en.json land. Following the direction question on #58.