bug(opensearch): optimize() resolves working index without the .os tag in phase 3 (index_not_found)

[fabrizzio-dotCMS]

Problem Statement

Under ES→OS migration phase 3 (OpenSearch-only), ContentletIndexAPIImpl.optimize() looks up the working index by its bare name without the .os suffix, so the lookup hits a non-existent index and throws index_not_found_exception.

Observed while running existing ITs under phase 3 via the opensearch-phase-suite profile (PR #36268):

ContentletIndexAPIImplTest.optimize <<< ERROR!
Caused by: ElasticsearchStatusException[Elasticsearch exception [type=index_not_found_exception,
  reason=no such index [cluster_2adf77e6d5.working_1782406288469]]]

The OS index set is registered with the .os tag (cluster_….working_….os), but the optimize path resolves/queries the untagged name — the same .os-tagging asymmetry seen elsewhere in the router.

Steps to Reproduce

./mvnw verify -pl :dotcms-integration -Dcoreit.test.skip=false \
  -Dopensearch.phase.test=true -Dopensearch.phase=3 \
  -Dit.test=ContentletIndexAPIImplTest

optimize errors with index_not_found for the working index missing the .os suffix.

Acceptance Criteria

• optimize() resolves the active working/live index names with the .os tag under phases that route to OpenSearch.
• ContentletIndexAPIImplTest.optimize passes under phase 3.
• No regression in phase 0 (ES) behavior.

dotCMS Version

main (dev / 1.0.0-SNAPSHOT) — ES→OS migration work.

Severity

Medium

Links

Found via blast-radius experiment in PR #36268 / issue #36266. Related test-decoupling: #36320.