Test env: OS content-index field-limit saturation + heap circuit-breaker under full integration suite (phase 2)

Found during the phase-2 integration triage (#36501). These are TEST-ENVIRONMENT artifacts, NOT product bugs — confirmed by isolation: the affected tests pass when run alone under phase 2; they only fail late in the full ~1705-test run.

Symptoms (full-suite phase-2 run only)

• Limit of total fields [10000] has been exceeded + MappingOperationsOS - putMapping failed ... HTTP 400 — the shared OS content index accumulates dynamic-template fields across the whole suite until the 10k field limit is hit; subsequent OS content indexing fails fire-and-forget, so docs never land in OS and phase-2 reads return 0. Affects (only in the long run): ContentletIndexAPIImplTest.removeContentFromIndexByStructureInode, .test_indexContentList_ContentTypeWithPageDetailNotExists, .testRemoveContentFromIndex, .test_that_live_and_working_content_makes_it_into_the_index.
• circuit_breaking_exception (HTTP 429, parent breaker, container heap exhausted) late in the run → ESContentFactoryImplTest.testIndexSearchFilteringByDateTime / ByTime fail after passing earlier.

Action (test profile, not product)

Raise/manage the OS content-index index.mapping.total_fields.limit and the OS container heap / indices.breaker.total.limit for the opensearch-phase-suite / upgrade test profile; and/or reduce cross-test field accumulation on the shared index.

Secondary product hardening (separate)

ContentFactoryIndexOperationsOS.cachedIndexSearch swallows a transient OS error (429/circuit-breaker) into ERROR_HIT (total=0) — under phase 2 (OS is the read source) a transient error silently becomes "0 results". Consider a bounded retry / louder signal before returning ERROR_HIT. (This same swallow masks the D12 auto-expire bug under #36501.)

Related: #36501.

Run the full phase-2 integration suite and compare the named isolated tests, including ContentletIndexAPIImplTest and ESContentFactoryImplTest. Start with the opensearch-phase-suite and upgrade test profiles, then inspect ContentFactoryIndexOperationsOS.cachedIndexSearch for the secondary hardening work. Done means the full suite avoids field-limit and heap-breaker failures, with transient errors no longer silently becoming zero results.