feat(i18n): ship the visitor form in all seven supported languages

[ph33nx]

199 visitor-facing strings translated into de, es, fr, hi, pt, ru, tr: form labels, help text, section headings, form titles, buttons, consent and error messages.

Domain vocabulary practitioners use untranslated stays transliterated (ayanamsa, nakshatra, panchang, kundli, gun milan, dosha), matching the convention already in the codebase.

Why bundled rather than waiting for wordpress.org

This is the documented on-ramp, not a shortcut. Per the wp.org meta handbook: shipped .mo files are imported into translate.wordpress.org to seed the project, language packs generate once a locale reaches 90%, and at that point the bundled copies can be removed. Verified on a real render that they load with no load_plugin_textdomain() call and nothing in wp-content/languages.

Verified live, all seven

Locale	Section	Label	Button
es_ES	Datos de nacimiento	Fecha de nacimiento	Calcular carta
de_DE	Geburtsdaten	Geburtsdatum	Chart berechnen
fr_FR	Données de naissance	Date de naissance	Calculer le thème
pt_BR	Dados de nascimento	Data de nascimento	Calcular mapa
tr_TR	Doğum bilgileri	Doğum tarihi	Haritayı hesapla
ru_RU	Данные рождения	Дата рождения	Рассчитать карту
hi_IN	जन्म विवरण	जन्म तिथि	कुंडली बनाएँ

Quality checks

• Placeholder integrity asserted per string: %s / %1$s counts must match the source or the build fails.
• French elisions restored (l'ayanamsa, d'une, J'accepte) after an early pass stripped them, which is a grammar error rather than a style choice.
• Turkish filter labels corrected from ele alma (reads as "do not handle") to yok say.
• 0 empty strings, 0 placeholder mismatches across all seven.

Formats

Ships .po (editable source), .mo, and .l10n.php (the WP 6.5+ format that avoids parsing .mo per request). phpcs now excludes languages/ for the same reason it excludes src/Generated: those files are emitted, not authored.