fix(os-search): honor track_total_hits and _score sort on the OpenSearch read path (#36501)

[fabrizzio-dotCMS]

Proposed Changes

Two OpenSearch read-path gaps found running the integration suite under ES→OS migration phase 2 (reads from OpenSearch). Both have a working ES reference implementation. Contributes to #36501.

• track_total_hits — OSIndexProperty.TRACK_TOTAL_HITS had no ES fallback key, so an existing ES_TRACK_TOTAL_HITS config was ignored under OS reads and OS always returned the full accurate count. Added the ES_TRACK_TOTAL_HITS fallback (same dual-key pattern as USE_FILTERS_FOR_SEARCHING).
• _score sort — ContentFactoryIndexOperationsOS.addSorting, for sortBy=score, added only the secondary field sort and never a primary _score sort, so results ordered by moddate and hit[0] was not the highest-scoring doc. Added the _score DESC primary sort (mirrors ContentFactoryIndexOperationsES.addSorting; API matches OSContentletScrollImpl).

Verification

Phase 2, isolated env: ESContentFactoryImplTest 42/0/0 (incl. Test_TrackHits_SearchCount and testScore, previously failing). Core compiles.

Refs #36501, #36320.

[claude]

Claude finished @fabrizzio-dotCMS's task in 2m 20s —— View job

---

Rollback-Safety Analysis — PR #36557

• Read docs/core/ROLLBACK_UNSAFE_CATEGORIES.md
• Get full PR diff (ContentFactoryIndexOperationsOS.java, OSIndexProperty.java)
• Evaluate diff against every unsafe category
• Post verdict / apply label

Verdict: ✅ Safe to rollback — label AI: Safe To Rollback applied.

Why: Both changes are pure query-construction logic evaluated at search time, not storage/schema/mapping changes:

• OSIndexProperty.java — adds an ES_TRACK_TOTAL_HITS fallback key to the existing TRACK_TOTAL_HITS enum entry (OS_TRACK_TOTAL_HITS, null → OS_TRACK_TOTAL_HITS, "ES_TRACK_TOTAL_HITS"). This only changes which config key is consulted when building a search request; no data, index mapping, or DB schema is touched. N-1 simply ignores the new fallback and keeps its old behavior.
• ContentFactoryIndexOperationsOS.java — adds a _score DESC primary sort() clause to the OpenSearch SearchRequestBuilder for sortBy=score queries. This affects only the ordering of search results returned to the caller for that one request; it doesn't alter the ES/OS index mapping, stored documents, DB rows, or any REST/GraphQL response shape.

No category in the reference doc applies: no runonce migration task, no putMapping()/mapping change, no contentlet_as_json version bump, no DROP/RENAME, no PK change, no new field type, no storage-provider change, no VTL viewtool contract change, and no REST/GraphQL/OSGi public contract change — this is internal, request-scoped search behavior. Rolling back to N-1 restores the prior (already-existing, previously-working per the PR's own description) behavior with no data or index incompatibility.