CollaborationItem schema advertises full File/Folder; list-collaborations returns mini (no owned_by) #618

Description of the issue

The generated API reference for GET /files/:id/collaborations (and folder collabs) shows a full nested `item` including `owned_by`. Live responses always return the mini item (`type`, `id`, `etag`, `sequence_id`, `name`). `fields=owned_by` and `fields=item.owned_by` do not expand nested item. This mismatched example has hurt a major customer's trust in Box docs.

Root cause in this spec: `CollaborationItem` is `oneOf: File | Folder | Web Link` (standard), so the docs generator renders the large example. Contrast GET `/folders/:id/items`, which correctly `$ref`s `File--Mini`.

Related: `marker` on these operations says it requires `usemarker=true`, but there is no `usemarker` parameter. File listing is marker-only. Folder listing defaults to offset (`total_count`); pass `marker=` to switch to marker paging.

Proposed change

PR: (linked once opened) from `ploomis-box:fix/collab-item-mini-docs`

• `CollaborationItem` → `File--Mini | Folder--Mini | WebLink--Mini`
• Describe that nested `item` cannot be expanded with `fields`; hydrate via GET file/folder `?fields=owned_by`
• Asana-style callout on the two list operations
• Fix `marker` copy (no `usemarker`)

Not in scope: adding `owned_by` to this endpoint. That is a File System / `#public-api-service-support` product ask. File System's direction for new collab-list endpoints is keep `item` mini and require a follow-up GET.

Open question for DevRel (Łukasz): mini/standard/full variant labeling was removed from API ref pages some time ago. Restoring it site-wide is separate from this schema fix.

Live contract (2026-09-23, CCG)

• POST `/collaborations`, GET `/collaborations/{id}`, GET file/folder collabs: mini `item`, never `owned_by`
• `fields=owned_by` on list: entries become `{type,id}` only
• `GET /files/{id}?fields=owned_by`: works (hydrate workaround)
• `usemarker=true`: silently ignored (HTTP 200)