Expose allomorphs (IMoForm) so interlinearizer AllomorphRef can resolve

Split out from sillsdev/interlinearizer-extension#26 (see the triage comment and the follow-up). Sibling issue: #2559 (MSA / GrammarRef).

Problem

The interlinearizer's interlinear model references allomorphs by GUID via AllomorphRef (src/types/interlinearizer.d.ts):

export interface AllomorphRef {
  /** `IMoForm.id` (GUID). */
  allomorphId: string;
  projectId?: string;
}

Nothing in the lexicon stack can resolve that GUID today:

• MiniLcm has no allomorph model. Entry carries a LexemeForm (MultiString) and a MorphType (MorphTypeKind), but individual IMoForm objects — the lexeme form and the alternate forms hanging off an entry — are not represented. The only place IMoForm appears is backend/FwLite/FwDataMiniLcmBridge/Api/LcmHelpers.cs, where it is created internally and immediately collapsed into Entry.LexemeForm. Allomorph identity (the GUID) is lost.
• The Platform.Bible lexicon extension exposes nothing for it. platform.bible-extension/src/types/lexicon.d.ts does not export an allomorph type, and IEntryService has no allomorph methods. Consumers can only infer detail indirectly from IEntry.lexemeForm and IEntry.components.

#2249 closed the analogous gaps for entries and senses by adding getEntry / getSense. This is the same shape of request for allomorphs, except that it also requires new model surface, not just a new lookup.

Ask

1. Add an allomorph model to MiniLcm (stable Id, form as a MultiString, MorphTypeKind, owning entry id, and whether it is the entry's lexeme form vs. an alternate form).
2. Read/write it in the FwData bridge (IMoForm ⇄ MiniLcm) and in the CRDT/Harmony bridge, and surface it on the FwLiteWeb routes.
3. Export the type from platform.bible-extension/src/types/lexicon.d.ts and add a by-id lookup on IEntryService — getAllomorph(projectId, allomorphId) or equivalent — so AllomorphRef resolves without walking entries.

Scope note

Point 1 fans out further than the interlinearizer JSDoc suggests: adding a MiniLcm model means touching the FwData bridge, the CRDT bridge, sync, and the FwLiteWeb API surface, not just re-exporting an existing type. Worth sizing before committing — it may be worth splitting the MiniLcm/backend work from the extension-surface work.

Blocks

• sillsdev/interlinearizer-extension#189 — Analysis Catalog: morpheme rows

Start by reading backend/FwLite/FwDataMiniLcmBridge/Api/LcmHelpers.cs, then inspect the CRDT/Harmony bridge and FwLiteWeb routes to map how existing lexicon models are read, written, synced, and exposed. Compare the requested model with platform.bible-extension/src/types/lexicon.d.ts and IEntryService; done means an allomorph can round-trip through the bridges and resolve by ID through the extension API.