review(R26): swap assertEquals arg order to (expected, actual)

R26 caught one assertEquals call at line 1139 in
testZonemapConsolidatedCommitShape with reversed JUnit 5 argument
order: `assertEquals(fragmentsIndexed, expectedFragments.size())`.
JUnit's signature is `assertEquals(expected, actual, message)`,
where the test author's known ground truth goes in the expected
slot and the value-under-test in the actual slot. With the
arguments swapped, a failure prints "expected: <SQL return> but
was: <dataset fragment count>" — misleading operators who'd
correlate the message against what they think the system should
do, not against the SQL return.

Swap to `assertEquals(expectedFragments.size(), (int) fragmentsIndexed)`.

Reset clean counter to 0/10.

Test count: 38 (unchanged), make lint passes, all green on 3.5/2.12.

Author: LuciferYang

lance-spark-base_2.12/src/test/java/org/lance/spark/update/BaseAddIndexTest.java

@@ -1137,8 +1137,8 @@ public void testZonemapConsolidatedCommitShape() {
       }
     }
     Assertions.assertEquals(
-        (int) fragmentsIndexed,
         expectedFragments.size(),
+        (int) fragmentsIndexed,
         "fragmentsIndexed return value must match the dataset's current fragment count");
     // Without >=2 fragments the "single segment vs N segments" shape is indistinguishable
     // from the distributed path's N=1 degenerate case.