Async /data-export job flow appears broken post-refactor, failures silently swallowed

# Async /data-export job flow appears broken post-refactor, failures silently swallowed

## Summary
The separate, async job-based `/data-export` flow looks broken after a refactor: `DataExportRequest` no longer carries `sites`/`devices`/`airqlouds` fields, but `doc_to_data_export_request` and the Celery task still read `doc["devices"]`/`doc["sites"]`/`request.airqlouds`, which should raise `KeyError`/`AttributeError`. This is currently swallowed silently, so failures in this path don't surface anywhere.

## 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 separate from the main sync data-download path but worth a look.

## Affected code
- `views/v2/data.py:133`
- `models/data_export.py` — `DataExportRequest`, `doc_to_data_export_request`
- The Celery task consuming these documents

## Suggested fix
Determine whether this async flow is still meant to be live. If yes, fix the field mismatch between `DataExportRequest` and the code that still reads `devices`/`sites`/`airqlouds` off it, and stop swallowing the resulting exceptions silently. If it's dead code, remove it to avoid confusion with the sync path.

## Acceptance criteria
- [ ] Determined whether the async `/data-export` job flow is still in use
- [ ] If live: field mismatch fixed and errors surface instead of being silently swallowed
- [ ] If dead: removed