Work Items API returns `labels` as UUIDs in list responses but as objects in single-item responses

[futzlarson]

Fetching work items via the list endpoint returns labels as an array of bare UUID strings, while fetching a single work item returns labels as an array of full label objects. Same field, same project, different type — so a consumer that reads one endpoint's shape breaks on the other.

Expected

labels has one consistent shape across both endpoints, or the difference is documented.

Actual

GET /workspaces/{slug}/projects/{project_id}/issues/ — bare UUIDs:

{
  "id": "11111111-1111-1111-1111-111111111111",
  "labels": [
    "22222222-2222-2222-2222-222222222222",
    "33333333-3333-3333-3333-333333333333"
  ]
}

GET /workspaces/{slug}/projects/{project_id}/work-items/{id}/ — full objects:

{
  "id": "11111111-1111-1111-1111-111111111111",
  "labels": [
    {
      "id": "22222222-2222-2222-2222-222222222222",
      "name": "Bug",
      "color": "",
      "sort_order": 295535,
      "project": "44444444-4444-4444-4444-444444444444",
      "workspace": "55555555-5555-5555-5555-555555555555"
    }
  ]
}

Neither request passes expand.

This matters when merging labels rather than replacing them. PATCH expects an array of UUIDs, so code that reads the current labels off a work item to preserve them has to normalize both shapes first, or it silently sends objects back and drops every label on the item.

Details

• Endpoints: GET .../issues/ and GET .../work-items/{id}/
• API: REST API (api.plane.so, cloud)
• Impact: consistent, not intermittent — the two endpoints always disagree.

Possibly related to #9534, which is the same class of problem on state (bare UUID returned despite ?expand=state).