Inject parquet settings in testSearchCommandWithSpecialIndexName

The test creates `logs-2021.01.11` and `logs-7.10.0-2021.01.11` directly
via raw PUTs to exercise the parser's handling of dot/version-prefixed
index names. The raw path bypasses `TestUtils.createIndexByRestClient`,
so the analytics-engine `tests.analytics.parquet_indices=true` toggle
never injects the composite/parquet settings. On the analytics-engine
route this surfaces as `Table 'logs-2021.01.11' not found` (the
catalog-builder only exposes indices that match an analytics-engine-
recognized data format), failing the test.

Routing the creates through `TestUtils.createIndexByRestClient` makes
both code paths honor the toggle: legacy / Calcite continues to create
plain Lucene-backed indices, analytics-engine gets parquet-backed
composite indices. The index names are still tested verbatim.

Surfaced by `CalciteSearchCommandIT` on the analytics-engine route.

Signed-off-by: Kai Huang <ahkcs@amazon.com>

Author: ahkcs

integ-test/src/test/java/org/opensearch/sql/ppl/SearchCommandIT.java

@@ -54,10 +54,15 @@ public void testSearchCommandWithoutSearchKeyword() throws IOException {
 
   @Test
   public void testSearchCommandWithSpecialIndexName() throws IOException {
-    executeRequest(new Request("PUT", "/logs-2021.01.11"));
+    // Route through TestUtils so the analytics-engine parquet-indices toggle
+    // (tests.analytics.parquet_indices=true) applies the composite/parquet
+    // settings; without them the analytics-engine planner can't find a backend
+    // for the scan and the query 500s.
+    org.opensearch.sql.legacy.TestUtils.createIndexByRestClient(client(), "logs-2021.01.11", null);
     verifyDataRows(executeQuery("search source=logs-2021.01.11"));
 
-    executeRequest(new Request("PUT", "/logs-7.10.0-2021.01.11"));
+    org.opensearch.sql.legacy.TestUtils.createIndexByRestClient(
+        client(), "logs-7.10.0-2021.01.11", null);
     verifyDataRows(executeQuery("search source=logs-7.10.0-2021.01.11"));
   }