V2 POST /record-types/{id}/views creates views that crash the Planning UI view switcher ("Unsupported view type")

## Summary

Creating a view through the **V2 API** (`POST /v2/record-types/{recordTypeId}/views`) returns `201 Created` and the view reads back correctly, but the **Planning web UI crashes** whenever that view is present in the record type's view switcher. The console throws:

> `Error: Unsupported view type: TIMELINE` — at `ViewIcon.tsx`

and the page shows *"Whoops! Something went wrong."* Views created **in the UI**, and the default **Table** view auto-created with a record type, render normally — so the problem is specific to views created via the public V2 API.

## Environment

- Workfront Planning V2 API — `https://.sb01.workfront.adobe.com/maestro/api/v2` (sandbox)
- Auth: `apiKey` header
- Observed: June 2026

## Steps to reproduce

1. Use a record type that has records with date fields (so a timeline can render).
2. Create a view via the API:

```http
POST /v2/record-types/{recordTypeId}/views
Content-Type: application/json

{
"name": "Roadmap",
"type": "TIMELINE",
"recordTypeId": "Rt...",
"filter": [],
"grouping": [{ "fieldId": "F...", "direction": "asc" }],
"sorting": [],
"metadata": {
"type": "TIMELINE",
"startDateKey": "F...startDate",
"endDateKey": "F...endDate",
"timelineScale": "MONTH",
"showRecordColoring": true
}
}
```

→ `201 Created`. `GET /v2/record-types/{id}/views` returns the view with `type: "TIMELINE"`, the grouping, and the metadata, exactly as sent.
3. Open that record type in the Planning UI and open the **view switcher** dropdown.

## Actual result

The UI crashes (*"Whoops! Something went wrong."*) with a console error:

```
Error: Unsupported view type: TIMELINE
at ViewIcon.tsx:25
```

The same occurs with `"type": "TABLE"` (`Unsupported view type: TABLE`). The crash fires as soon as the API-created view is in the switcher list — even when a different (working) view is selected — because the switcher renders an icon for every view.

## Expected result

A view created via the API should render in the UI exactly like a view created in the UI.

## Notes / investigation

- I diffed an **API-created** TIMELINE view against a **UI-created** TIMELINE view of the same record type: the returned JSON is **identical** apart from `id` / `name` / grouping `fieldId`. So the property the UI's `ViewIcon` switches on is **not present in the view's stored/returned payload** — it appears to be state initialized only when a view is created in the UI (or for the auto-created Table view from record-type creation), and **not** by `POST .../views`.
- The same record type's **auto-created Table view renders fine**, and **UI-created views render fine** — only API-created views crash.
- `PATCH /v2/views/{id}` works (`200`). `DELETE /v2/views/{id}` sometimes returns `403`. Setting `isHidden: true` on the API-created view removes it from the switcher and stops the crash (a usable workaround).

## Impact

View configuration (timeline views, grouping, coloring) can't be **provisioned via the API** — it has to be done by hand in the UI. This blocks automated / templated workspace setup.

## Request

Either fix `POST /v2/record-types/{id}/views` to fully initialize a view so the UI renders it, or document the required additional field/step (and ideally have the docs note that views must currently be created in the UI).

---

_Happy to share request IDs and the exact before/after view JSON. I observed similar "created but not fully initialized" behavior on other V2 create endpoints (e.g. create-field dropping `dateOptions` / `numberOptions`), which I can file separately if useful._

Start at POST /v2/record-types/{recordTypeId}/views and compare its returned view with a UI-created view, then inspect ViewIcon.tsx and the view switcher entry point. Verify the initialization difference for API-created TIMELINE and TABLE views; done means those views render in the switcher without the Unsupported view type error.

Written by the indexing model from the issue text.