[TEST] Add a multi-shard integration test CI lane

Problem

Integration tests run against one primary shard by default. Queries and assertions that depend on unspecified encounter order can therefore pass in CI but return different results on real multi-shard indices. PR #5730 fixes several examples, and #5716 demonstrates the same class of behavior for FIRST, LAST, and TAKE.

OpenSearch core addresses this behaviorally. OpenSearchIntegTestCase randomizes index shard counts from 1 to 10, and its assertion helpers distinguish ordered results from order-insensitive membership checks. FieldSortIT.testSortDuelBetweenSingleShardAndMultiShardIndex is a concrete single-shard versus multi-shard comparison for sorted top results.

References:

• https://github.com/opensearch-project/OpenSearch/blob/main/test/framework/src/main/java/org/opensearch/test/OpenSearchIntegTestCase.java#L611
• https://github.com/opensearch-project/OpenSearch/blob/main/test/framework/src/main/java/org/opensearch/test/hamcrest/OpenSearchAssertions.java#L263-L307
• https://github.com/opensearch-project/OpenSearch/blob/main/server/src/internalClusterTest/java/org/opensearch/search/sort/FieldSortIT.java#L2036

Proposal

1. Add a route-independent tests.integ.num_shards override in TestUtils.createIndexByRestClient with a default of 1.
2. Apply the override only when the index definition does not explicitly set number_of_shards.
3. Forward the property through integTest and integTestRemote.
4. Add one Linux CI lane that runs integTest with three primary shards. Start it as non-required while existing failures are triaged, then make it required once green.

Start at TestUtils.createIndexByRestClient and trace how the integTest and integTestRemote tasks pass properties. Compare the referenced OpenSearchIntegTestCase and FieldSortIT examples, then inspect the repository's CI configuration. Done means an opt-in three-primary-shard Linux integTest lane runs successfully without overriding explicit shard counts.