Extract merge-field markup into a shared module

[jbedient-kizen]

Independent of the email-template stack — base main, no dependency either way.
Pulls merge-field markup into one shared module and fixes two real defects found
while writing it.

Why a module

A merge field is not a bare {{ ns.field }} token. That renders as literal
braces in a recipient's inbox. Kizen's builder always wraps it:

<spanclass="kzn-merge-field"
data-merge-field-fallback-label="Stage"
data-merge-field-relationship="object_with_workflow.stage"
data-merge-field-objectname="object with workflow">{{ object_with_workflow.stage }}</span>

That markup appears in automation notify steps, call_llm and
file_content_extraction prompts, dashboard static text, and email template
text blocks. Only the automations planner knew how to build it. tools/merge_fields.py
now owns token parsing, span rendering, and namespace classification; callers
pass small resolver callables for live field/object display names, so the module
depends on no caller's types.

Two defects fixed

1. The token regex matched exactly one dot. So
{{ custom_objects.primary_document_record.id }} — present in a committed
fixture — never matched, fell through to html.escape, and rendered as visible
braces in a recipient's message. Now one-or-more segments, with a test naming
the fixture so it can't be narrowed back.

2. Namespace classification used lookup success.data-merge-field-objectname
is emitted only for real custom-object namespaces, and the old code decided that
by asking whether a live object lookup succeeded. contact is itself a queryable
object api_name but is a reserved namespace that carries no objectname, so it
was misclassified. Now an explicit allowlist, with a test asserting the resolver
isn't even called for reserved namespaces.

The label table

Labels are authoring-time snapshots, not functions of the token. Verified: the
same token carries different labels in different automations
(custom_objects.name is CD Activity Name in one and object with workflow Name
in another). So live field metadata resolves them wherever it can, and a static
table covers only namespaces with no queryable metadata source.

For business/team_member the table is complete, not a sample — every entry
in both builder pickers was inserted into a template and read back, and the counts
match the pickers exactly (12 and 5).

These labels can be neither derived nor fetched:

• GET /api/docs/schema's Business component lists 40 properties, not these 12,
  and omits country_code/state_code entirely
• no merge-field catalog endpoint exists — 0 of 564 schema paths match "merge"
• a "<Namespace> " + title(api_name) rule gets 11 of 17; postal_code →
  Zip/Postal Code and primary_marketing_contact_name → Primary Name are not
  reachable by any casing transform

automation_history is deliberately excluded from the table for the reason above.

Reviewing

7 files, +728/-85. The automations planner's three private merge-field helpers are
removed in favour of the module; behaviour there should be unchanged except for the
two fixes.

Worth challenging: the 17 pinned labels are only as good as the capture they came
from. An earlier revision of this work had two label values rejected in review as
unevidenced, correctly — they existed only in a chat message. If any look wrong,
say so and they'll be re-captured rather than argued for.