Fix DataForSEO backend (never returned data) and urllib3 incompatibility

[dspv]

Hi! Thanks for the tool — the 429 problem it solves is real, and the DataForSEO backend idea is exactly right. I hit two issues trying to use it for market research, so here are fixes.

1. urllib3 2.x breaks the free backend

pytrends 4.9.2 (its latest release) calls Retry(method_whitelist=...), which urllib3 removed in 2.0. A fresh pip install trends-checker resolves urllib3 2.x, so every request fails:

[error] US: Retry.__init__() got an unexpected keyword argument 'method_whitelist'
No summary data produced.

Pinned urllib3<2. Since 4.9.2 is pytrends' latest, this can't be fixed by bumping it.

2. The DataForSEO backend never returned a row

$ trends-checker --keywords "vibe coding,ai agents" --dataforseo-key user:pass
DataForSEO request failed: 'list' object has no attribute 'get'
Falling back to Google Trends...

📊 DataForSEO Trends (no rate limits)
───────────────────────────────────────────────────────
                                     <- nothing, and exit 0

The parser didn't match the API's real response shape:

• it read item["keyword"], but the graph item carries keywords (a list);
• it read item["data"]["values"], but data is a list of time points, each holding a values array parallel to keywords. .get() on that list raised AttributeError, which the bare except swallowed — printing "Falling back to Google Trends..." even though no fallback path exists. The command then exits 0 with an empty table, which is easy to mistake for "no data" in a cron job;
• --geo, --group and --timeframe were never sent: every query ran worldwide / web / past-12-months regardless of flags.

This PR resolves each --geo to a location_code via the /locations endpoint (fetched once per process), maps --group and --timeframe to DataForSEO's dialect, queries per region, and prefers the API's precomputed averages.

Two small judgment calls, happy to change either:

• Unsupported input warns instead of silently substituting. An unmapped --timeframe and countries missing from Trends' location list (e.g. RU, which is in DEFAULT_GEOS) previously would have quietly returned a different period/region than requested.
• A region that falls back to worldwide is labelled RU -> WW, not RU — a [RU] header over worldwide numbers seemed worth avoiding.

Verification

Against the live API, geo filtering now demonstrably applies:

$ trends-checker --keywords "vibe coding,ai agents" --geo US,GB --dataforseo-key ...
[US]
  ai agents      [████████░░░░░░░░░░░░] 43/100
  vibe coding    [█░░░░░░░░░░░░░░░░░░░] 8/100
[GB]
  ai agents      [███████░░░░░░░░░░░░░] 35/100
  vibe coding    [██░░░░░░░░░░░░░░░░░░] 11/100

And the two backends now agree — pytrends returns 42.51 / 8.26 for US, DataForSEO 43 / 8. Also checked: WW, --group youtube, --timeframe "today 5-y", an unmapped timeframe, and a clean venv install (urllib3 resolves to 1.26.20, free backend works).