[views] /v2 views API contract (review aid for #694, not for merge)

[ruolin59]

Important

This PR is a reading aid, not a merge candidate. #694 is the change under review and the one that would merge. This branch reproduces only the wire models from it, with nothing else, so the API contract can be read without the surrounding implementation. Please leave review comments on #694 unless they're specifically about the shape of these five files.

Extracted from #694 in response to the feedback that 5k lines gets a shallow review. 273 lines across five files, no tests, no wiring, nothing called by anything.

The contract

CreateUpdateViewRequestBody — viewId, databaseId, clusterId, schema, representations, sourceDialect, defaultCatalog, defaultNamespace, viewProperties, baseViewVersion. representations is a list of ViewRepresentation {type, sql, dialect} rather than a scalar sql field, so a second dialect can be added later without changing the shape.

GetViewResponseBody — the pointer and row-backed identity. SQL, schema and history stay in the Iceberg metadata file, which the client already reads through its own FileIO.

GetAllViewsResponseBody — paginated from the first release, reusing GetViewResponseBody for its elements populated with identifiers only, matching how the v2 table search behaves.

ViewErrorCode — all fourteen failure modes declared now, including the ones M1 never emits, so later milestones add behaviour without changing the enum. It selects an HTTP status and is never serialized; the shared ErrorResponseBody is untouched.

Where the rest lives

Everything else is in #694 and is not duplicated here:

ViewApiContractTest	freezes every field set and JSON key set above
ViewsController, ViewsApiHandler	the five /v2 routes and their delegation
OpenHouseViewsApiValidator	structural validation
ViewsService / ViewsDisabledService	the stubbed service seam
ViewDto, ViewsMapper	internal model and mapping

For context on why the contract is shaped this way rather than following the Iceberg REST spec, see the feasibility comparison and the discussion on #694.