[TASK] Adjust Index Routing Logic on ESContentFactoryImpl & ESIndexAPI

Description

The underlying classes have already been refactored and separated. This task focuses on refining and organizing the routing logic so that the appropriate delegate methods are invoked on the target index provider according to the current migration phase.

The phase is provided as an integer value that maps to the MigrationPhase enum, which defines the routing behavior for read and write operations between Elasticsearch and OpenSearch.

Acceptance Criteria

The routing logic is refined so that the coordinating class determines which delegate methods to invoke based on the current migration phase.
•	The migration phase is provided as an integer and correctly mapped to the MigrationPhase enum.
•	The appropriate index provider delegates are invoked according to the defined migration phases:
•	Phase 0 – Migration Not Started: All read and write operations are routed only to Elasticsearch.
•	Phase 1 – Dual Write (ES Reads): Write operations are routed to both Elasticsearch and OpenSearch, while read operations continue to be served by Elasticsearch.
•	Phase 2 – Dual Write (OS Reads): Write operations are routed to both Elasticsearch and OpenSearch, while OpenSearch serves read operations.
•	Phase 3 – OpenSearch Only: All read and write operations are routed only to OpenSearch.
•	The routing logic remains centralized in the coordinating class.
•	Existing delegate implementations remain unchanged and are invoked only through the routing logic.
•	No regression is introduced in the current indexing behavior.

Priority

None

Additional Context

No response

Start by reading ESContentFactoryImpl, ESIndexAPI, and the MigrationPhase enum to trace how the coordinating class currently selects delegate methods. Verify each read and write path against the four migration phases, then confirm existing delegate implementations remain unchanged and indexing behavior has no regressions.