What does this PR do?

Adds the POST /v2/apps.listApps endpoint, which returns a cursor-paginated list of apps belonging to a given project.

The SQL query backing this endpoint was updated to support cursor-based pagination: it now filters by id >= id_cursor, orders by id ASC, and accepts a LIMIT parameter. Previously the query ordered by created_at with no pagination support.

The handler:

• Looks up the project by workspace and ID, returning 404 if not found
• Enforces project.*.read_app or project.<project_id>.read_app permissions, returning a 404 (rather than 403) on authorization failure to avoid leaking project existence to unauthorized callers
• Fetches limit + 1 rows to determine whether more pages exist, then trims the result and sets the cursor and hasMore fields in the pagination response

OpenAPI schemas and the generated YAML were updated to include V2AppsListAppsRequestBody (with projectId, limit, and cursor fields) and V2AppsListAppsResponseBody (with data, meta, and pagination fields). Speakeasy cursor pagination metadata is included.

Tests cover:

• 200: empty project, populated project, cross-project isolation, non-existent cursor, cursor borrowed from a foreign workspace, and full pagination traversal
• 400: missing/invalid projectId, out-of-range limit
• 401: invalid bearer token
• 403/404: missing permissions, cross-workspace project access, and an existence oracle test asserting that unauthorized responses for real and nonexistent projects are indistinguishable

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Chore (refactoring code, technical debt, workflow improvements)
• Enhancement (small improvements)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How should this be tested?

• Call POST /v2/apps.listApps with a valid root key and a projectId that belongs to your workspace; verify a 200 response with the correct apps and pagination fields
• Call with limit: 2 against a project with more than 2 apps and follow the cursor across pages; verify all apps are returned exactly once and the final page has hasMore: false and no cursor
• Call with a root key that lacks read_app permission; verify a 404 is returned and no project or app IDs are present in the response body
• Call with an invalid projectId (too short, invalid characters, too long) or an out-of-range limit; verify a 400 validation error is returned
• Run the unit tests in svc/api/routes/v2_apps_list_apps/

Checklist

Required

• Filled out the "How to test" section in this PR
• Read Internal Workflow Guide
• Self-reviewed my own code
• Commented on my code in hard-to-understand areas
• Ran pnpm build
• Ran pnpm fmt
• Ran mise run fmt
• Checked for warnings, there are none
• Removed all console.logs
• Merged the latest changes from main onto my branch with git pull origin main
• My changes don't cause any responsiveness issues

Appreciated

• If a UI change was made: Added a screen recording or screenshots to this PR
• Updated the Unkey Docs if changes were necessary