Add i18n/localization infrastructure (starting with Spanish support)

## Problem

Buzz currently ships with UI strings hardcoded in English across all three frontend clients (`desktop/` — Tauri + React, `web/`, and `mobile/` — Flutter). There is no i18n/localization infrastructure in any of them:

- No `i18next`, `react-intl`, `formatjs`, `lingui`, or `next-intl` in `package.json` (root or `desktop/`)
- No Flutter `intl` package wired up in `mobile/`
- No `locales/` or `i18n/` directories in any client
- Text appears to be embedded directly in JSX/TSX components (desktop/web) and widget code (mobile)

This makes the app inaccessible to non-English-speaking users/teams, even though Buzz is meant to be a shared workspace for humans *and* agents across teams. A community member requested help changing the interface to Spanish, which surfaced that there's currently no path to do this at all — not even a partial one.

## Proposal

Before writing any translation strings, agree on an approach for adding i18n infrastructure, scoped to one client first:

1. **Pick a starting client** — desktop (Tauri + React) is the primary UI most users interact with day-to-day, so it seems like the natural first target. Web and mobile would follow the same pattern once the approach is validated.
2. **Pick a library** — for the React/Tauri desktop client, `react-i18next` (or `formatjs`/`react-intl`) are the common choices. Happy to write up a short comparison if useful.
3. **Extract strings incrementally** — sweep `desktop/src/features/` and `desktop/src/shared/` to move hardcoded strings into a translation-key system, defaulting to `en` with no behavior change.
4. **Add a language selector** in settings, defaulting to system locale with an override.
5. **Add a first non-English locale** (e.g. `es`) as the initial proof that the pipeline works end-to-end.

This is a fairly invasive change (touches most UI files) so I wanted to check in before starting any implementation, per CONTRIBUTING.md's guidance to open an issue first for substantial work.

## Questions for maintainers

- Is i18n already on the roadmap / being tracked elsewhere?
- Any preference on library or scope (e.g. desktop-only first vs. all three clients in parallel)?
- Would maintainers want string extraction done as one large PR or incrementally per-feature?

Happy to pick this up (starting with a proposal/RFC-style PR for the desktop client) once there's agreement on direction.