Create LivingDictionary issue and pr for LIFT export

https://github.com/livingtongues/living-dictionaries

Issue draft, possibly to post with a companion pr implementing it:

Title: Native LIFT export — a portable, tool-neutral copy of a community's dictionary

What this is

A proposal to add LIFT as a second structured export format alongside CSV (revisiting #44, closed in 2024, and complementing the export improvements discussed in #627).

LIFT ("Lexicon Interchange FormaT") is a plain-XML file format designed specifically for moving dictionary data between programs. It is a common interchange format of the language documentation ecosystem: FieldWorks, The Combine, WeSay, ELAN (for interlinearized texts), and Dictionary App Builder all read it, and archives accept it.

Spec: https://github.com/sillsdev/lift-standard (stable v0.13 is widely used; there are no active plans to proceed to the proposed v0.14 or v0.15).

Why it helps Living Dictionaries communities

• Data ownership becomes portable in practice, not just in principle. Communities own their data on the platform; a LIFT export lets them take it anywhere — into desktop tools for offline work, into The Combine for expansion via Rapid Word Collection, into a mobile-app builder, into an institutional archive — without a bespoke converter per destination.
• CSV can't carry the structure a dictionary actually has. The current CSV export flattens multi-sense entries, keeps only the first audio/photo/sentence, and exports semantic domains as translated display text. LIFT natively represents entries → senses → examples, multiple writing systems per headword, audio/photo references, and stable entry ids (so a later re-import can update rather than duplicate).

Why it's smaller than it sounds

• Writing LIFT is much easier than parsing it — an exporter only emits the subset of constructs that the Living Dictionaries model has; it never faces the full spec's optionality or malformed input. Realistically a few hundred lines of dependency-free TypeScript: a multitext helper (LD's MultiString maps 1:1 onto LIFT's <form lang><text> pattern), per-entry/sense serialization, XML escaping, and a .lift-ranges companion file for the semantic-domain and part-of-speech vocabularies.
• EntryData is already assembled identically on server and client, so the exporter is a serializer over an existing read model, not new data plumbing.

Start by reviewing the existing CSV export and the shared EntryData read model, including how MultiString values are represented on server and client. Then compare the model fields with the LIFT v0.13 specification and define the export and .lift-ranges scope. Done means a dependency-free TypeScript exporter can represent the supported dictionary data in valid, portable LIFT output.