Fix for LT-22563

[AndyBlack]

This turned out to be a continuation of LT-22422 "XAmple can incorrectly report success for a variant referring to an entry with multiple MSA" The fix there took care of Try a Word, but not what fed into the parser filer. This fixes that.
The result from XAmple can include MSI elements like these:


which have three parts: the lex entry hvo, the lex ref hvo. and the msa hvo. We were ignoring the msa hov when passing the XAmple parsing result to the parser filer.

---

This change is 

[github-actions]

NUnit Tests

    1 files  ±0      1 suites  ±0   10m 21s ⏱️ +51s
4 302 tests +3  4 229 ✅ +3  73 💤 ±0  0 ❌ ±0 
4 311 runs  +3  4 238 ✅ +3  73 💤 ±0  0 ❌ ±0 

Results for commit f6e1099. ± Comparison against base commit b7c9ce5.

♻️ This comment has been updated with latest results.

[johnml1135]

General comment (not diff-anchored — this file isn't touched by this PR, so GitHub won't let me attach it to a line):

Src/Utilities/pcpatrflex/ToneParsFLExDll/ToneParsInvoker.cs, TryCreateParseMorph/ProcessMsaHvo (~line 799-891)

This class's TryCreateParseMorph/ProcessMsaHvo is explicitly labeled "from XAmpleParser.cs" (see the comment at line 729: "ConvertParserFilerResultXmlToParseResult(), TryCreateParseMorph(), and ProcessMsaHvo() are from XAmpleParser.cs ... Ideally, we'd expose them from XAmpleParser.cs"). It still has the old 2-tuple ProcessMsaHvo that discards the MSA hvo — the exact bug this PR fixes for XAmple. Since ToneParsInvoker is a live, separately-tested class (see ToneParsInvokerTests.cs), the PC-PATR/tone-parser path will still reproduce the "valid parse not in the list" symptom from LT-22563/LT-22422 for entries with multiple MSAs. Might be worth either applying the same fix there, or (per the existing TODO) finally exposing ProcessMsaHvo/TryCreateParseMorph from XAmpleParser.cs so there's one implementation.

[johnml1135]

General comment (not diff-anchored — no test files are touched by this PR):

Missing test coverage for the fixed code path

Neither XAmpleParserTests.cs nor ParseFilerProcessingTests.cs exercises TryCreateParseMorph/ProcessMsaHvo against a 3-part MSI DbRef (e.g. 19938.0.14573) resolving to an IMoStemMsa. This is exactly the kind of format-parsing detail that regressed silently once already (LT-22422 fixed the writer side but not the parser-filer side, which is what led to LT-22563). A regression test mirroring the JIRA acceptance test — a variant LexEntry with multiple MSAs parsed through ParseWordXml/TryCreateParseMorph — would guard against this reappearing in a future refactor.

[johnml1135]

All thee comments AI generated - human review forthcoming.

[AndyBlack]

General comment (not diff-anchored — this file isn't touched by this PR, so GitHub won't let me attach it to a line):

Src/Utilities/pcpatrflex/ToneParsFLExDll/ToneParsInvoker.cs, TryCreateParseMorph/ProcessMsaHvo (~line 799-891)

This class's TryCreateParseMorph/ProcessMsaHvo is explicitly labeled "from XAmpleParser.cs" (see the comment at line 729: "ConvertParserFilerResultXmlToParseResult(), TryCreateParseMorph(), and ProcessMsaHvo() are from XAmpleParser.cs ... Ideally, we'd expose them from XAmpleParser.cs"). It still has the old 2-tuple ProcessMsaHvo that discards the MSA hvo — the exact bug this PR fixes for XAmple. Since ToneParsInvoker is a live, separately-tested class (see ToneParsInvokerTests.cs), the PC-PATR/tone-parser path will still reproduce the "valid parse not in the list" symptom from LT-22563/LT-22422 for entries with multiple MSAs. Might be worth either applying the same fix there, or (per the existing TODO) finally exposing ProcessMsaHvo/TryCreateParseMorph from XAmpleParser.cs so there's one implementation.

I will create a separate JIRA issue for this.

[AndyBlack]

Missing test coverage for the fixed code path
I wish I knew how to create unit tests for these kinds of things. I've never been able to figure out how to do it; hence, there aren't any. Do you have ideas on how it could be done?

[johnml1135]

Added a regression test for this in c350a58: ParseFilerProcessingTests.TryCreateParseMorph_IrregularVariantWithMultipleMsas_UsesMsaFromDbRef.

It builds an irregularly inflected variant entry ("creb") of a base entry ("seek") that has two MSAs, invokes the private XAmpleParser.TryCreateParseMorph (via reflection) with a hand-built <Morph><MoForm DbRef="..."/><MSI DbRef="lexEntryHvo.0.msaHvo"/></Morph> element pointing at the second MSA — mimicking what XAmple echoes back — and asserts the resulting ParseMorph.Msa is that exact second MSA, not the variant's first/main sense (which is what the pre-fix code would have produced via GetMainOrFirstSenseOfVariant). Confirmed it exercises the fixed path by tracing it against the still-unfixed duplicate of this logic in ToneParsInvoker.cs (flagged in an earlier comment), which would return the wrong (first) MSA for this same setup.

[johnml1135]

Looks good - just make sure the new JIRA issue is linked.

[johnml1135]

@johnml1135 reviewed 3 files and all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on AndyBlack).

[johnml1135]

New JIRA issue: https://jira.sil.org/browse/LT-22607