docs(preview): add conversation attributes endpoints

[dan0505]

Why?

Implements the new conversation attributes API from PR #506882. Conversation attributes were previously served through the shared /data_attributes endpoint, which didn't properly represent conversation-specific fields like multiline, options, and reference. A dedicated API gives us a purpose-built shape.

How?

Added new CRUD endpoints at /conversations/attributes with a dedicated response schema hierarchy that returns type-specific fields per data_type. Updated /data_attributes to deprecate the model=conversation parameter, which now returns a 422 error in the Preview API version.

_{Generated with Claude Code}

[adisan19]

OpenAPI Spec Review

Nice work on the API surface design — the sub-resource pattern for options, asymmetric create input, and comprehensive error examples are all well done. A few things to address:

1. 🔴 created_at / updated_at: type vs format mismatch

created_at:
  type: integer
  format: date-time   # ← contradicts type: integer

format: date-time is defined by OpenAPI/JSON Schema as RFC 3339 strings (e.g. "2026-05-20T12:00:00Z"). The example values are Unix timestamps (1777473061), which is correct for type: integer — but code generators (openapi-generator, Stainless, etc.) will see format: date-time and emit DateTime types, then fail to deserialize the integer at runtime.

Fix: Remove format: date-time and clarify in the description:

created_at:
  type: integer
  description: Unix timestamp when the attribute was created.

2. ⚠️ Inline request body on PUT /conversations/attributes/{id}

The update endpoint defines its request body schema inline, while every other mutating endpoint uses a $ref to a named schema in components/schemas. This makes the update request body invisible to code generators that build typed request classes from named schemas.

Fix: Extract to update_conversation_attribute_request in components/schemas, consistent with create_conversation_attribute_request.

3. ⚠️ conversation_attribute_list claims pagination but has none

The description says "A paginated list of conversation attributes" but the schema only has type and data — no pages, total_count, or cursor fields. Either:

• Add pagination fields if the API actually paginates, or
• Change the description to "A list of conversation attributes"

4. ⚠️ Missing required array on conversation_attribute response schema

The conversation_attribute schema lists all properties but never declares which are guaranteed present. Without a required array, strict-mode code generators treat every field as optional. At minimum type, id, name, data_type, and archived should be marked required.

5. 💡 additionalProperties: false on strict request schemas

The option endpoints validate strictly server-side (e.g. "only 'label' is accepted"). Adding additionalProperties: false to create_conversation_attribute_option_request and update_conversation_attribute_option_request would make the spec match the server's actual validation and let client-side validators catch bad requests early.

[marcmlc]

we seem to be using a create_conversation_attribute_request schema for post endpoint, should we do the same here for put?

we also already have create_conversation_attribute_option_request and update_conversation_attribute_option_request

[marcmlc]

should we have some conversation_attribute_option_not_found code instead? might need to change the code in intercom tho

[marcmlc]

missing the pagination params here

        total_count:
          type: integer
          description: A count of the total number of objects.
          example: 12345
        pages:
          "$ref": "#/components/schemas/cursor_pages"