fix: show Farsi/Dari instead of Persian in the language filter

[Cy-fox]

Closes #404

The opportunity language filter was showing "Persian" as the checkbox label
because it used the raw title returned by the API options endpoint. However,
the rest of the UI (volunteer profiles, opportunity profiles) refers to this
language as "Farsi/Dari" using the languageNames translation section. The
mismatch meant users looking for Farsi/Dari speakers could not find the
correct filter option.

Changes:

• Opportunities/Filters/helpers.ts: language label resolver now looks up
  the API title in the languageNames translation namespace (with fallback
  to the raw title), making filter labels consistent with how languages
  appear in profiles
• translations (EN/DE): added "persian": "Farsi/Dari" to languageNames so
  the API title "Persian" maps to the display name "Farsi/Dari"

[nadavosa]

PR #416 Review: Show Farsi/Dari instead of Persian in the language filter

Fix is correct. key.toLowerCase() maps the API's "Persian" → "persian" → locale key languageNames.persian → "Farsi/Dari". Both EN and DE locale files are updated. No missing locales, no broken imports.

One latent issue worth being aware of:

Low: Fallback detection assumes i18next returns the key string verbatim on a miss
translated !== translationKey works correctly with the current i18next configuration (saveMissing: false, no parseMissingKeyHandler). If those are ever configured, the fallback breaks silently. A more defensive approach is to maintain a Set of known language keys, but it's low-risk with the current setup.

Info: Dot-in-key risk (pre-existing)
i18next uses . as its key separator. If the API ever returns a language name containing a dot, the lookup would be misinterpreted as a nested key. Not introduced by this PR and low-probability given the current data — just worth knowing since this PR now relies on the pattern for correctness.

[nadavosa]

Fix is correct and complete. The i18next key-based fallback handles the Persian→Farsi/Dari mapping cleanly, and both locale files are updated. The two notes in my earlier comment (fallback detection assumption, dot-in-key risk) are low/informational — nothing blocking. Approving.