fix(hermitcrab): make metathesis switch-name order not matter

[johnml1135]

Problem

A MetathesisRule whose leftSwitch names the earlier of its two pattern groups throws instead of producing an analysis:

System.InvalidOperationException: Failed to compare two elements in the array.
---> System.ArgumentException: Only nodes from the same list can be compared. (Parameter 'other')
at SIL.Machine.Annotations.ShapeNode.CompareTo(ShapeNode other)
at SIL.Machine.Annotations.ShapeRangeFactory.Compare(ShapeNode x, ShapeNode y)
at SIL.Machine.Annotations.Range`1.CompareTo(Range`1 other)
at System.Linq.Enumerable.EnumerableSorter`2...
at SIL.Machine.Morphology.HermitCrab.Morpher.Synthesize(...)

Both metathesis specs silently required the opposite orientation. Every pre-existing test in MetathesisRuleTests names the later group as the left switch, so the intuitive order was never exercised.

Direction is not involved — this reproduces under both LeftToRight and RightToLeft.

Cause

MoveNodesAfter advances its cur anchor after every iterated node, whether or not that node was physically moved. In the failing orientation beforeRightGroup ends up equal to leftGroup.Range.End, so for a single-node group that node is simultaneously the move's anchor and the node being removed in the same iteration. node.Remove() sets its List to null and the following cur.AddAfter(node) never restores it. The orphaned node then reaches morph.Children.OrderBy(ann => ann.Range), and ShapeNode.CompareTo throws because the two nodes belong to different lists.

Separately, AnalysisMetathesisRuleSpec builds its pattern in leftSwitch-then-rightSwitch order, but that pattern must match the surface, where the two groups appear in the opposite order from the underlying form. With the switch names reversed the analysis pattern matched nothing — so even with the crash fixed there was still no analysis.

Fix

Both specs order the two switch groups by pattern position rather than by name, so a rule behaves identically whichever way its switch names are written.

For rules that already name the later group first the normalization is a no-op: the swap condition is false, and AnalysisMetathesisRuleSpec emits the same order it always did.

Verification

Full SIL.Machine.Morphology.HermitCrab.Tests suite: 71/71 pass. dotnet csharpier check clean.

Each half of the fix was reverted independently to confirm both are load-bearing:

Reverted	Result
synthesis normalization	SimpleRule_LeftSwitchNamesEarlierGroup and its right-to-left variant reproduce the reported crash
analysis normalization	all three new tests fail with an empty analysis instead
neither	71/71 pass

Tests added:

• SimpleRule_LeftSwitchNamesEarlierGroup — differs from SimpleRule only in the switch-name order, and must give the same result
• SimpleRule_LeftSwitchNamesEarlierGroup_RightToLeft — same, with Direction.RightToLeft
• ComplexRule_LeftSwitchNamesEarlierGroup — reversed naming with a group between the two switches. Note this one passes even without the synthesis change; it guards the analysis-side ordering and the middle-group case rather than reproducing the crash.

Scope, and what this does not close

This fixes the switch-name-order crash class. Two pre-existing hazards in the same code are left untouched and are not claimed to be fixed:

• MoveNodesAfter still advances cur past a skipped non-Segment node, so a switch group whose own range spans a boundary or anchor node could still anchor subsequent moves off a stale position. No current rule shape hits this.
• An unmatched switch capture has a null Range.Start. beforeRightGroup's .Prev already dereferenced it before this change; the new comparison is guarded with GroupCapture.Success so it does not add a second such site, but the underlying assumption that both switches always match is unchanged.

How it was found

While building generated-coverage fixtures for the HermitCrab XML surface on the conformance-framework branch: a fixture written to exercise MetathesisRule@multipleApplicationOrder wrote its switch names in the natural order and hit this. The ordering attribute turned out to be irrelevant.

🤖 Generated with Claude Code

---

This change is 

[codecov-commenter]

Codecov Report

❌ Patch coverage is 91.66667% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 73.32%. Comparing base (3093bd2) to head (03026ed).

Files with missing lines	Patch %	Lines
...b/PhonologicalRules/SynthesisMetathesisRuleSpec.cs	83.33%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #471 +/- ##
=======================================
Coverage 73.31% 73.32% =======================================
Files 445 445 Lines 37300 37310 +10 Branches 5115 5118 +3 =======================================
+ Hits 27346 27356 +10 
Misses 8827 8827 Partials 1127 1127 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ddaspit]

@ddaspit reviewed 3 files and all commit messages, and made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on johnml1135).