[Data] Close Hebrew terminology gap and honest bilingual UX

Problem summary

Marketing and i18n claim a bilingual interface (hero_stat_bilingual), but ICD-10 (~74k records) has zero name_he fields. Selecting Hebrew changes UI chrome but not terminology display names for major schemes.

Affected area

• data/vocabularies/icd10.json (no name_he)
• app/components/CodeCard.tsx (falls back to name_en)
• i18n/locales/*.json
• assets/data/ (contains some Hebrew demo labels not merged into runtime data)

Expected behavior

When Hebrew is selected, users see Hebrew terminology where available, with an honest fallback indicator when only English labels exist.

Actual behavior

Hebrew UI language mostly affects chrome strings. ICD-10 and other full datasets display English names only with no explanation.

Acceptance criteria

• Short term: show "English only for this scheme" chip when name_he is absent.
• Medium term: merge available Hebrew labels from demo assets into runtime vocabularies for high-traffic codes.
• Update marketing copy to "9 UI languages" or qualify bilingual claims until terminology coverage improves.
• Document Hebrew coverage per scheme in DATA_SOURCES.md.

Start with app/components/CodeCard.tsx and data/vocabularies/icd10.json to trace the current Hebrew fallback, then compare assets/data/ with the runtime vocabularies and review i18n/locales/*.json. Check DATA_SOURCES.md and the marketing copy before making changes. Done means missing Hebrew coverage is identified in the UI, available labels are merged where specified, claims are qualified, and coverage is documented per scheme.