Feature: i18n / language selector for desktop UI (start with zh-CN)

### Motivation

Buzz Desktop currently ships with English-only UI strings. Non-English speakers (e.g. Chinese-speaking teams running Buzz as an internal hive-mind platform) hit a language wall on day one: onboarding ("Create a new identity key"), Settings panels, channel/thread controls, notifications, and agent-status surfaces are all hardcoded English.

I hit this deploying Buzz 0.5.23 on Linux for a Chinese-speaking user: the app works great (WebGL rendering, STT models, relay connectivity all fine), but every UI string is English. This limits adoption in mixed-language teams and for non-technical colleagues who would otherwise be able to use Buzz as their daily communication hub.

Searching the codebase, desktop UI strings appear hardcoded in components (e.g. `settingsSections` labels in `desktop/src/features/settings/ui/SettingsPanels.tsx`), with no i18n framework present.

### Proposed solution

Introduce an i18n layer in the desktop (React) app:

1. **Adopt a standard i18n framework** — e.g. `react-i18next` / `i18next` or `lingui` — and extract hardcoded UI strings into message catalogs (en as source of truth).
2. **Language selector in Settings → Appearance** — persisted per user (localStorage is already used for app state), defaulting to the OS locale.
3. **Ship zh-CN as the first community translation** — Chinese is likely the largest non-English audience; a `zh-CN.json` catalog would get the app usable for a large group immediately.
4. Keep strings in one place per feature module so catalog updates stay low-churn as the UI iterates (0.5.x ships fast).

### Alternatives considered

- **Hardcoded per-language forks** — unmaintainable; desktop resources are bundled into the binary, so every release needs a rebuild.
- **Browser-level / system-level translation (e.g. translate shell overlays)** — not viable inside WebKitGTK, and machine translation of a trust-sensitive comms tool is poor UX.
- **Upstreaming later, starting with a community patch** — possible, but without an i18n framework in place there's nothing to hang translations on.

### Additional context

- Verified in v0.5.23 deb build on Linux: no `Language` section in Settings, no i18n framework (i18next / lingui / react-intl) referenced in the desktop bundle.
- Prior art: Tauri + React apps commonly use `react-i18next`; Electron/Tauri comms apps (e.g. Element) ship full i18n with community catalogs via Weblate/Transifex.
- Duplicate check: none found (searched open/closed issues for i18n / translation / language).