Custom fields with dots in names break segment filtering, workflow conditions, and template rendering

[chamby]

Bug Description

When contacts have custom fields with dots in their names (e.g., prefix.key), dynamic segments fail to match any contacts. The same issue affects workflow condition evaluation and email template variable rendering.

Steps to Reproduce

1. Create contacts with custom data fields that contain dots in the key name (e.g., {"app.plan": "premium"})
2. Create a dynamic segment with a filter on that field (e.g., data.app.plan equals premium)
3. Observe that the segment matches zero contacts, even though contacts exist with that value
4. Rename the field to use a different separator (e.g., app|plan) and the segment works correctly

Root Cause

Contact custom field data is stored as a flat JSON object in the data column:

{"prefix.key": "value"}

However, three code paths split field names on . to build path lookups, which interprets prefix.key as a nested path (data.prefix.key) instead of a literal key (data["prefix.key"]):

1. SegmentService.buildJsonFieldCondition — jsonPath.split('.') creates a multi-element Prisma JSON path array, causing the query to look for nested data -> prefix -> key instead of the flat key data -> "prefix.key"
2. WorkflowExecutionService.resolveField — splits on every . to traverse the data object, failing to find the literal key
3. template.ts getValue — path.split('.').reduce() tries to traverse nested objects instead of looking up the literal key

Impact

• Dynamic segments: Conditions on dotted custom fields match zero contacts
• Workflow conditions: CONDITION steps referencing dotted fields always evaluate to false
• Email templates: {{data.prefix.key}} renders as empty in emails

Expected Behavior

Custom field names containing dots should be treated as literal key names, not as nested path separators. Users should be free to use any characters (including dots) in their custom field names.