feat(api): Publish typed issue view creation endpoint

[cvxluo]

Publish the issue view creation endpoint. Redux of #122537
Cover it in the agent-token public API matrix with the required feature flag and payload.

Refs IS-15

[linear-code]

IS-15

[sentry]

Bug: The timeFilters field in GroupSearchViewPostValidator uses a DictField without a child validator, allowing malformed dictionary structures to pass validation and be saved to the database.
_{Severity: MEDIUM}

Suggested Fix

To enforce the expected structure at runtime, replace the DictField with a nested serializer. Define a GroupSearchViewTimeFiltersSerializer with fields for start, end, period, and utc, and use it as the validator for the timeFilters field. This will ensure that only correctly structured data is accepted. Additionally, add a test case that attempts to create a view with malformed timeFilters to verify that the request is rejected.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: src/sentry/api/serializers/rest_framework/groupsearchview.py#L37-L39

Potential issue: The `GroupSearchViewTimeFiltersField` is defined as a `DictField`
without a `child` validator. While the OpenAPI schema is decorated to expect a specific
structure for `timeFilters`, the runtime validation does not enforce it. This allows any
non-empty dictionary to be accepted, regardless of its keys or value types. An API
client can send a malformed `timeFilters` object, such as `{"randomKey":
"randomValue"}`, which will be successfully validated and stored in the database. This
can lead to unexpected behavior or errors in the frontend when the
`normalizeDateTimeParams` function processes this corrupted view configuration.

Also affects:

• src/sentry/api/serializers/rest_framework/groupsearchview.py:83~88

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[wedamija]

This reminded me that I never merged #122950, just merged it now. Could you rebase on this so we can verify that this won't break master?