Confirm frontend follows pagination cursor; silent truncation past the 10,000-row export limit

# Confirm frontend follows pagination cursor; silent truncation past the 10,000-row export limit

## Summary
`Config.DATA_EXPORT_LIMIT` (default 10,000) caps each page of a data-download response; pagination continues via a `cursor` field rather than an error. It's unconfirmed whether the frontend download flow actually follows `cursor` through every page — if it only reads page one, a large multi-device/long-range export would silently ship partial data with no indication anything was cut off.

## Where this came from
Baalmart, following up on AirQo-frontend PR #3876's data-download review, tracing the request path in `src/analytics`. Flagged as a strong candidate for "download has only metadata even though preview showed data" reports beyond the plain zero-data case.

## Affected code
- `Config.DATA_EXPORT_LIMIT` — `config.py:47`
- Cursor-based pagination — `bigquery_api.py:500-553`

## Suggested fix
Confirm with the frontend team whether the nexus download flow follows `cursor` across pages. If not, either fix the client to paginate, or make the API return an explicit `truncated: true` / `total_rows` signal so a silent cutoff can't happen either way.

## Acceptance criteria
- [ ] Confirmed (and documented) whether the frontend paginates through `cursor` for exports near/over 10,000 rows
- [ ] If it doesn't, either the client is fixed or the API signals truncation explicitly