Add sku property to ecommerce_catalog_variant schema

[harish-intercom]

Why?

Adds an optional sku (stock-keeping unit) string property to the ecommerce_catalog_variant schema, matching the corresponding property already documented on the public API reference.

How?

Keeps this repo's OpenAPI description in sync with the public API reference schema.

_{Generated with Claude Code}

[shrek-intercom]

✅ PR Review Summary: APPROVE

	Summary
✅	🎯 Problem — The PR clearly describes the problem (schema out of sync with public API reference) and the rationale, though it could be improved by noting the impact or linking to the API reference.
✅	📝 Alignment — The description accurately reflects the code change: an optional nullable sku string property added to the ecommerce_catalog_variant schema with no omissions or phantom claims.
ℹ️	🧠 Correctness — Disabled for this repository.
✅	🦺 Safety — The change is purely additive — a single new optional sku string field added to the Unstable/Preview spec only — meeting the auto-approve criteria for safe, additive changes.
✅	🚦 Auto-approval — Within size limit (0/150 LOC).

Per-criterion details

Problem

The PR clearly explains the problem (schema out of sync with public API reference) and the why (keeping OpenAPI description aligned). It's concise and focused, though it could slightly improve by mentioning the impact of the mismatch or linking to the API reference.

Alignment

The PR description states it adds an optional sku (stock-keeping unit) string property to the ecommerce_catalog_variant schema, and the diff confirms exactly this:

1. Property added: A sku property is added with type: string, nullable: true, a description, and an example value — all consistent with an "optional string property."
2. Schema location: The property is added within the ecommerce_catalog_variant schema (the next schema definition visible is ecommerce_catalog_product), matching the description.
3. File changed: Only descriptions/0/api.intercom.io.yaml is modified, which matches the listed files changed.
4. Scope: The description says it keeps the OpenAPI spec in sync with the public API reference — while I can't verify the external reference, the change itself is straightforward and accurately described.

No omissions of significant changes, no phantom claims, and no scope mismatch. The description accurately reflects what the code change does.

Safety

This PR adds a single new optional property (sku) to the ecommerce_catalog_variant schema in descriptions/0/api.intercom.io.yaml — the Unstable/Preview spec. The change is purely additive: it introduces a new string, nullable field with a description and example. No existing fields are removed, modified, or renamed. No released version specs (descriptions/2.*/) are touched. No Fern stable overrides, scripts, CI/CD workflows, or configuration files are affected. This is exactly the type of change the auto-approve criteria designate as safe: an additive change confined to the Unstable/Preview tier.

<violated_criteria>
</violated_criteria>

_{Rate this comment 👍 / 👎 to help us improve 🙏 · Disagree with assessment? Establish ground truth here}