Add lexicon ref resolution when copying a Paratext 9 import for editing

src/converters/pt9/lexiconResolver.ts、pt9ImportService、analysisMerger.ts、bareWordAnalyses.ts、Pt9ImportModal.tsx から着手し、ブロックされている issue #226 をもとに authority の規約を確定します。createEditableCopy と PT9 のインポートレポートを追跡し、refs が編集可能なコピー後も維持されること、および折りたたまれた sense の合計についてのカバレッジを追加します。完了の条件は、PT9 のインポートで refs が生成され、コピーがそれらを保持し、レポートが表示動作を変更せずに sense の合計をレンダリングすることです。

The PT9 import stack ships a lexicon-resolution seam with nothing plugged into it, so every import
persists gloss text and no lexicon refs. That deferral (#273) is right for the import project
itself. It is not right for an editable copy, which is the one place PT9 lexeme identity becomes
unrecoverable.

Current state

• The seam exists and is fully wired. Pt9LexiconResolver
  (src/converters/pt9/lexiconResolver.ts) offers
  resolveEntry(key) -> EntryRef and resolveSense(key, senseId) -> SenseRef. Every ref site the
  converter can produce already calls it: morpheme entryRef / senseRef and token-level
  glossSenseRef in analysisMerger.ts, morpheme refs on
  bare-word payloads in bareWordAnalyses.ts. Outcomes are
  counted in the import report (senses.entryRefsResolved / entryRefsUnresolved, same for senses).
• Nothing supplies an implementation. pt9ImportService.importPt9Project calls
  convertPt9Project({ data, books, importedAt }) with no resolver, so
  unresolvedPt9LexiconResolver applies, every lexeme counts as unresolved, and imported analyses
  carry inlined gloss text and zero refs.
• The identity is in the payload, not missing. Pt9InterlinearProjectData.lexicon carries
  entries keyed by composed lexeme-key id and senses with ids and per-language glosses - the same
  data pt9GlossSource already reads for gloss text. For PT9
  the seam's work is minting refs from data in hand, not looking anything up.

Why the copy is the case that matters

lexiconResolver.ts records the current rationale: a PT9-authority ref "would store fine as a
foreign ref, but nothing would ever resolve it; re-importing recovers the identity instead."

That holds for the import project, which is frozen and replaced wholesale by savePt9Import on
every run. It does not hold for a copy:

• createEditableCopy clones the analysis, keeps sourceProjectId, and drops pt9Import.
• Re-import finds its target through getPt9ImportForSource, which matches on pt9Import. A copy
  carries none, so no re-import ever touches one.

So the artifact the user actually edits and keeps is the one artifact whose dropped PT9 lexeme
identity cannot be recovered. Re-importing produces a fresh import project; the user's edits stay
behind in the old copy, still refless.

Ask

• Implement a PT9-authority resolver over the served Pt9Lexicon and pass it from
  pt9ImportService.
• Name the authority constant (paratext9, following whatever convention #226 fixes).
• Decide projectId. PT9's lexicon lives in the PT9 project, so the id space is partitioned and a
  ref must carry one. LexiconRef.projectId already anticipates exactly this: "an authority whose
  lexicon lives in a Paratext project may well use a Paratext project id here, even the analyzed
  project's own."
• Test the case this issue exists for: an import that carries refs, copied, still carries them.
• Fold and render report.senses in the import report summary. foldReport
  (Pt9ImportModal.tsx) deliberately leaves it out today, since with no resolver every run
  would show zero resolved; ReportTotals carries a TODO pointing here.

Display does not change, and must not. No registered resolver declares paratext9, so per
#225/#269 every minted ref is foreign - never resolved, never dropped, rendered as the stored
free-form gloss, which import already inlines. These refs are provenance now and resolvable later.

Open questions

• entryId is not a GUID here. The model documents EntryRef.entryId as IEntry.id (GUID); a
  PT9 ref carries a composed lexeme key (Stem:exauc, Word:a:2). Either that doc widens to
  "whatever the authority mints" or PT9 refs need a different shape. Widening looks right -
  authorities are opaque by design - but it should be written down, not assumed.
• Senses with no id. Pt9GlossOutcome.defaultSingle can produce gloss text from a sense carrying
  no id, and bareWordAnalyses only attempts a senseRef when the languages agree on exactly one
  id. Confirm an entry-only ref is the intended outcome there.
• Minting only, or a provider too? Minting is self-contained. Actually resolving these refs needs
  something that declares the paratext9 authority - a PT9 lexicon provider, which is a live
  candidate for the tier-1 slot in #46 and for #44's "create from Paratext 9 data." Mint regardless;
  whether this issue also provides is the open part.

Non-goals

No PT9 lexicon provider, no lexicon UI, no writes to any lexicon. Minting refs during import and
keeping them through createEditableCopy.

Blocked on

#226, for the convention naming an authority constant. This is the first code path in the repo that
mints a ref, and #226 exists partly so the first writer does not improvise a label that then
persists.

Relationship

Completes #150's scope item 3 (gloss-text resolution) on the identity half - #150's open question
"import to glossSenseRef vs. literal gloss text vs. both?" is answered here as both. What a
resolvable ref renders as is #227's ladder.