/v1/cubesql endpoint doesn't return 'Continue wait' for long-running queries

## Description

The [REST API documentation](https://cube.dev/docs/product/apis-integrations/core-data-apis/rest-api#cache-control) states that both `/v1/load` and `/v1/cubesql` endpoints support cache control and the Continue wait mechanism:

> `/v1/load` and `/v1/cubesql` endpoints of the REST API allow to control the in-memory cache behavior.

And in the [Continue wait section](https://cube.dev/docs/product/apis-integrations/core-data-apis/rest-api#continue-wait):

> If the request takes too long to be processed, the REST API responds with `{ "error": "Continue wait" }` and the status code 200.

However, when making a request to `/v1/cubesql` with a long-running query, the request hangs indefinitely instead of returning `{"error": "Continue wait"}` after `continueWaitTimeout`.

## Expected behavior

After `continueWaitTimeout` (e.g., 20 seconds), the `/v1/cubesql` endpoint should return `{"error": "Continue wait"}` with status 200, allowing clients to poll—the same behavior as `/v1/load`.

## Actual behavior

The request hangs indefinitely, never returning a Continue wait response.

## Configuration

- `continueWaitTimeout`: 20 seconds (configured via `orchestratorOptions.continueWaitTimeout` in `cube.js`)
- Cube.js version: 1.6.8

## Steps to reproduce

1. Configure `continueWaitTimeout` to a short value (e.g., 20 seconds)
2. Send a POST request to `/v1/cubesql` with a query that takes longer than the timeout
3. Observe that the request hangs instead of returning `{"error": "Continue wait"}`

## Question

Is Continue wait intentionally not supported for `/v1/cubesql`, or is this a bug? If intentional, the documentation should be updated to clarify this difference from `/v1/load`.

Start with the /v1/cubesql and /v1/load REST API entry points and trace how orchestratorOptions.continueWaitTimeout is handled for each. Reproduce with a query exceeding the 20-second timeout, then add or update coverage for the expected 200 response containing {"error":"Continue wait"} and verify clients can poll.

Written by the indexing model from the issue text.