fix(openapi): Standardize OpenAPI schemas and fix API response types (#2212)

## Summary

This PR refactors and fixes the OpenAPI specifications to better reflect
actual API responses and to follow consistent naming conventions,
primarily to improve the quality of generated client models.

## Issue

Closes: #2182

I consider this to be a last update from my side (at least for now).

## Key changes

### Schema naming standardization

- Rename response schemas to consistent patterns: `GetXResponse` /
`CreateXResponse` → `XResponse`.
- Rename list schemas: `XList` → `ListOfX`, `GetXListResponse
→`ListOfXResponse`.
- This results in clearer, reusable models and avoids duplicate schemas
with different names.

### Type fixes

- Add missing enums: `WebhookDispatchStatus`, `ScheduleActionType`,
`RunOrigin` (for `BuildsMeta.origin`)
- Add `ANYONE_WITH_NAME_CAN_READ` value to `GeneralAccessEnum`
- Add `ACTOR.STANDBY` to `WebhookEventType`
- Update usage schemas to use the `additionalProperties` pattern for
dynamic keys

### Schema cleanup

- Remove duplicate schemas (e.g., `PostAbortBuildResponse`,
`BuildActorResponse`)
- Remove placeholder fields (e.g. `foo`)
- Use `PaginationResponse` base for list schemas consistently
- Remove enum constraint from `SourceCodeFolder.folder`

### API response fixes

- Remove required constraints from optional API fields
- Fix schema to match actual API response (e.g. `WebhookDispatch`,
`WebhookEventType`, ...)
- Add missing schemas (e.g. `ListOfTasks`, `ListOfTasksResponse`, ...)

## Questions

A few questions for the Platform team (a full review would be greatly
appreciated):

- What is `GetOpenApiResponse.yaml` supposed to represent?
- It appears to be a meta-schema attempting to describe the full OpenAPI
3.x document structure, which causes code generators to produce many
unnecessary intermediate classes.
- The field `DATA_TRANSFER_EXTERNAL_GBYTES?` includes a question mark,
is that intentional?
- Is `ActorDefinition.default_memory_mbytes` intentionally defined as
`int` or `str`?
- Is `WebhookDispatchList.data` intentionally optional? It seems to be
the only optional `data` field.
- Please verify `WebhookDispatchStatus`; it is based only on observed
API responses in tests.
- Is `WebhookEventType` now correct with the `TEST` value?

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>

Author: vdusek

…hemas/actor-builds/GetBuildResponse.yaml …/schemas/actor-builds/BuildResponse.yamlapify-api/openapi/components/schemas/actor-builds/GetBuildResponse.yaml renamed to apify-api/openapi/components/schemas/actor-builds/BuildResponse.yaml apify-api/openapi/components/schemas/actor-builds/GetBuildResponse.yaml renamed to apify-api/openapi/components/schemas/actor-builds/BuildResponse.yaml

@@ -1,4 +1,5 @@
-title: GetBuildResponse
+title: BuildResponse
+description: Response containing Actor build data.
 required:
   - data
 type: object

apify-api/openapi/components/schemas/actor-builds/BuildsMeta.yaml

@@ -1,16 +1,15 @@
 title: BuildsMeta
 required:
   - origin
-  - userAgent
 type: object
 properties:
   origin:
-    type: string
-    examples: [WEB]
+    $ref: ../actor-runs/RunOrigin.yaml
   clientIp:
-    type: string
-    format: ipv4
+    type: [string]
+    description: IP address of the client that started the build.
     examples: [172.234.12.34]
   userAgent:
-    type: string
+    type: [string]
+    description: User agent of the client that started the build.
     examples: [Mozilla/5.0 (iPad)]

apify-api/openapi/components/schemas/actor-builds/GetBuildListResponse.yaml

@@ -1,4 +1,4 @@
-title: BuildList
+title: ListOfBuilds
 allOf:
   - $ref: ../common/PaginationResponse.yaml
   - type: object

apify-api/openapi/components/schemas/actor-builds/GetOpenApiResponse.yaml

@@ -0,0 +1,7 @@
+title: ListOfBuildsResponse
+type: object
+required:
+  - data
+properties:
+  data:
+    $ref: ./ListOfBuilds.yaml