fix(os-mapping): getFieldMappingAsMap must return the neutral (ES-shaped) map (#36501)

[fabrizzio-dotCMS]

Proposed Changes

MappingOperationsOS.getFieldMappingAsMap serialized the whole OpenSearch FieldMapping, producing the wrapper shape {"full_name":"...","mapping":{"<field>":{...}}}. The vendor-neutral contract (established by MappingOperationsES returning sourceAsMap(), keyed by the leaf field name) was violated, so callers doing map.get(fieldVariable) got null and NPE'd under migration phase 2. Now returns the inner mapping sub-map so the OS result matches the ES shape. Contributes to #36501.

Verification

Phase 2, isolated env: FieldAPITest 97/0/0 (incl. test_SaveNewIndexedField_ShouldAddESMapping and test_SaveNewRelationshipField_ShouldAddESMapping, previously NPE).

Refs #36501, #36320.

This PR fixes: #36501

[claude]

Claude finished @fabrizzio-dotCMS's task in 3m 18s —— View job

---

Rollback-Safety Analysis

Diff analyzed: 9a504735...1387dd1c — single file, MappingOperationsOS.java (+11/-2)

• Read docs/core/ROLLBACK_UNSAFE_CATEGORIES.md
• Reviewed full PR diff
• Checked against all unsafe categories (C-1..C-4, H-1..H-8, M-1..M-4)
• Verdict posted

Result: ✅ Safe to rollback

The change only reshapes a return value inside MappingOperationsOS.getFieldMappingAsMap (dotCMS/src/main/java/com/dotcms/content/index/opensearch/MappingOperationsOS.java:120-156) — it now unwraps the OpenSearch {"full_name":...,"mapping":{...}} wrapper and returns the inner mapping sub-map instead of the whole wrapper, matching the shape MappingOperationsES.getFieldMappingAsMap already returns.

Why none of the categories apply:

• No ES/OS mapping mutation (C-2): no call to putMapping()/indices().putMapping() — this method only parses an already-existing mapping response into a Java Map. The live index mapping is untouched.
• No schema/DB change (C-1, C-3, C-4, H-1..H-3, H-6, H-7, M-1): no runonce task, no SQL, no contentlet_as_json model touched.
• No API contract change (M-3): getFieldMappingAsMap is an internal API (IndexMappingRestOperations/ContentMappingAPI), not exposed via REST/GraphQL.
• No OSGi-exported interface break (M-4): the interface isn't part of a plugin-facing OSGi contract, and this PR doesn't alter the interface signature — only the internal implementation's return contents.
• No VTL/viewtool exposure (H-8): this class isn't registered as a Velocity viewtool and isn't reachable from templates.
• No storage provider change (H-5): unrelated to binary storage.

Net effect: this is a same-JVM bug fix — the old wrapper-shaped map was actively causing NPEs for callers (map.get(fieldVariable) returning null), so N-1 behavior after a rollback is simply "the pre-existing bug returns," not a new incompatibility. Nothing persisted (DB rows, ES/OS index mappings, JSON model version) changes shape, so N-1 continues to start and serve requests correctly.

Label AI: Safe To Rollback has been applied.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[ihoffmann-dot]

The fix is correct, minimal, and well-scoped. It aligns the OpenSearch path with the established ES vendor-neutral contract (sourceAsMap(), keyed by leaf field name), the cast is guarded (instanceof Map), and the behavior is exercised by FieldAPITest on the OS route.