Feature request: Gladly conversation timestamps report tables

<!-- req-ref: 1786125166.876479 --> ## What & why Handle-time, first-response, and wait-time analytics need Gladly's purpose-built report exports, which the source doesn't currently sync — without them, SLA reporting has to be reconstructed from raw item-level data, if it's even possible. ## Implementation plan - Research findings: Gladly's Reports API metric sets `ConversationTimestampsReport` and `ContactTimestampsReport` — how they're requested (likely an async report-generation + polling/download flow, common for "Reports API" style integrations; confirm from public docs at https://developer.gladly.com/rest/#tag/Reports), and how Fivetran's connector materializes them (cite this as the target shape/pattern, from public Fivetran docs if reachable). - Pattern to follow: this is likely a different sync shape than a normal REST list endpoint (report generation vs. list-and-paginate) — flag this clearly as a design consideration, not a simple `settings.py` entry. `products/warehouse_sources/backend/temporal/data_imports/sources/gladly/settings.py` currently models every stream as a vendor-scheduled export job (JSONL file per job, oldest-first, merge-on-`id`), which may not fit an on-demand/date-ranged report request. The closest existing async-report pattern in this repo is Checkout.com's `products/warehouse_sources/backend/temporal/data_imports/sources/checkout_com/reports.py` — it discovers report types dynamically, lists generated report files via a paginated `GET /reports` listing, and downloads + parses each file (CSV in that case), injecting `report_*` / `file_*` metadata columns. Use it as a reference for how this repo structures a reports-listing + file-download source, even though Gladly's flow may additionally require triggering report generation rather than only listing pre-generated files. - Concrete steps: - Files to add/modify: extend `products/warehouse_sources/backend/temporal/data_imports/sources/gladly/settings.py` with new endpoint config(s) for `conversation_timestamps` and `contact_timestamps` (or a combined table if the two metric sets share a shape), plus whatever new module is needed for report generation/polling/download (mirror the shape of `checkout_com/reports.py` if the vendor flow allows a listing, or add a poll-until-ready helper if it requires triggering generation first). - Check whether any other already-implemented source under `products/warehouse_sources/backend/temporal/data_imports/sources/` has an async-report-generation-then-poll pattern (trigger a report, poll a status endpoint, download when ready) to mirror more closely than Checkout.com's list-only flow — none was found with certainty in this pass; re-check before starting, since new sources are added continuously. - Primary key: likely the conversation/contact ID plus report period, but confirm against the actual report row shape once accessible. - Incremental strategy: match the existing Gladly convention of an injected cursor field if the report flow is job/date-range based (see `_JOB_INCREMENTAL_FIELDS` in `settings.py`), adapting for whatever cursor the Reports API actually exposes (report generation timestamp, period end date, etc.). - Tests: fixture-based sync tests following existing Gladly source test conventions, plus tests for any new report-generation/polling logic (success path, not-yet-ready/poll-retry path, failure path). - Open questions/risks: report generation latency and async semantics (how a report request is triggered, how readiness is signaled, whether results are paginated or a single file) are unconfirmed without a live Gladly account — verify against https://developer.gladly.com/rest/#tag/Reports before implementing. Write for a zero-context engineer/agent to execute async.