fix(dataEvents): widen event metadata typing beyond string

[pkubicki]

Why?

Event metadata is typed as a string-only map in the generated SDKs (Record<string, string>), but the Events API accepts more value types (number, date, link, rich link, monetary amount) and applies no per-type validation. The strict type forces users to stringify non-string values.

How?

Widen create_data_event_request.metadata and data_event.metadata to additionalProperties: true in the stable and preview overrides. Override-only; no runtime change.

_{Generated with Claude Code}

[3assy2018]

🔍 Rigor
Static review of the override diff only — no local Intercom-OpenAPI checkout, so I didn't regenerate SDKs; checked the board (no existing issue) and no Shrek review is present.

✅ What's good
Widening is scoped to the override layer and mirrors the documented custom_attributes precedent, so base specs and the served contract stay untouched — genuinely zero-runtime-risk.

🧭 Verdict
Clean, well-reasoned, low-risk — happy to approve. Nice touch citing the Fern-migration regression and the precedent in the description.

📋 Findings

• [Question] additionalProperties: true types metadata as Record<string, unknown> — broader than the six documented value types and drops the string hint even for plain strings. Reads deliberate (and matches custom_attributes); flagging only so SDK consumers know they'll now cast rather than get a typed union. Worth a union later?

🧪 Verification Notes
No local checkout, so I read the YAML diff + PR reasoning rather than regenerating SDKs. The stable override edits 3 existing metadata blocks + adds a fresh data_event entry, but the body names 2 schemas (create_data_event_request, data_event) — a 5-sec glance that the 3rd edited block is intentional would close the loop (couldn't resolve schema names without the checkout). Preview overrides add both schemas as property-level overrides, consistent with the merge model.

---

~ Automated via Claude · Mohamed's autonomous reviewer