[BUG] SDKv2 Pagination: endCursor is not exposed for stateless requests

**Describe the bug**
The `Page` object returned by `pipedream.apps.list` in the TypeScript SDK v2 does not expose the `endCursor` for the next page. While the method accepts an `after` parameter to specify a starting cursor, it provides no way to retrieve the cursor for the subsequent page from the response object. This prevents developers from implementing stateless, cursor-based pagination across multiple asynchronous requests, a feature that was available in the previous SDK version. The `rawResponse` object also does not contain the response body, making it impossible to extract the cursor from there.

**To Reproduce**
Steps to reproduce the behavior:

1. Initialize the Pipedream SDK v2 client.
2. Call the `pipedream.apps.list()` method to fetch the first page of apps.
```typescript
import { Pipedream } from "@pipedream/sdk";

const pipedream = new Pipedream({
auth: {
token: "YOUR_API_KEY",
},
});

const firstPage = await pipedream.apps.list();
```
3. Inspect the `firstPage` object.
4. Notice that there is no public property such as `endCursor` or `nextCursor` available to use for the next API call. It's only possible to get the next page via the stateful `getNextPage()` method.

**Expected behavior**
The `Page` object returned by `pipedream.apps.list` should expose the `endCursor` (or an equivalent `nextCursor` property) from the underlying API response. This would allow developers to store the cursor and pass it to a subsequent, independent `pipedream.apps.list({ after: storedCursor })` call, enabling stateless pagination.

**Additional context**
This is a regression from the previous SDK version where `pipedream.listApps` returned the `endCursor` directly. The current design only supports stateful pagination by holding the `Page` object in memory and calling `.getNextPage()`, which is not suitable for many server-side or web application architectures where requests are stateless.