[DEFECT] Key-Value fields in Widgets are converted to Strings instead of Maps

Problem Statement

When rendering a widget, Key-Value fields are being exposed to the Velocity context as plain strings instead of Map objects. This prevents any standard map operations and causes inconsistent behavior compared to regular content types.

Steps to Reproduce

Steps to Reproduce

1. Create a Content Type with a Key-Value field (e.g., questionList).
2. Create a Widget using this Content Type.
3. Add one or more key-value pairs (e.g., a=Value A, b=Value B).
4. Place the widget on a page or render it directly.
5. In the widget’s Velocity code, print the field and attempt to access keys:
6. $questionList

$questionList.a
$questionList.get("a")
$questionList.map.entrySet()

Observe that:

$questionList prints as a raw string: {a=Value A, b=Value B}
All key-based operations return null or errors
Map iteration fails completely

• Workaround : #set($me = $dotcontent.find($ContentInode))
• https://intranet.dotcms.com/support/kb/key-value-fields-in-widgets-issue-and-solution
• https://drive.google.com/file/d/15_VV2e6mRgkmk5xPPAsfHb8hR6C7o8i0/view?usp=sharing
• https://dotcms.freshdesk.com/a/tickets/34071

Acceptance Criteria

Key-Value fields inside widgets should behave like they do in standard content:

Return a proper Map<String, Object>
Support $field.key
Support $field.get("key")
Support iteration via .map.entrySet() or .keys

dotCMS Version

Latest evergreen

Severity

Medium - Some functionality impacted

Start by reproducing the widget rendering path with a Content Type containing a Key-Value field, then inspect how that field is exposed in the Velocity context. Compare it with standard content behavior and the documented $dotcontent.find($ContentInode) workaround. Done means the widget exposes a Map<String, Object> supporting key access, get(), and iteration as listed in the acceptance criteria.