Scraper API: send waitFor as an object, read the target status from http_code

[jehrr]

Two defects in scraper_api_client.py, both measured 2026-09-23 against https://scraper.2captcha.com/tasks/sync.

1. waitFor was sent as a JSON-encoded string. The live API now answers that with HTTP 422 params.waitFor must be an object — and still bills the task ($0.0005). So every run with --wait-text / --wait-element / --wait-state ended in exit 5. Sent as an object it answers 200. _build_wait_for now returns a dict (Optional[dict]), logged with json.dumps; its docstring says what was measured instead of claiming a string is required.

2. The target status was read from status. The response is {"status": "success", "http_code": <int>, …}: status is the API's verdict string, http_code the target's HTTP code. fetch_html returns the status to _run_once, which hands it to detect_page_state(html, status=…), so the classifier received "success" and a target 403/404/503 could not be read by its status. New _target_status() reads http_code (int), falling back to status only if that is an int.

Regression check — check_scraper_api_waitfor_object_and_http_code in smoke_test.py, picked up by the suite's check_ auto-discovery (defined above the CHECKS = [...] line, so it is collected): drives the real fetch_html with requests.post monkeypatched (no network), asserts the payload's waitFor is a dict for --wait-text 円, and that the status returned onward is the int 403 from a fake {"status":"success","http_code":403} response.

Control: with scraper_api_client.py restored to origin/main in a scratch copy (edit asserted to change the file), the suite went RED with both of this check's messages and no other failure; with the fix it is green (434 checks passed).

Live: one call through the fixed client, --wait-text 円, https://maison.kose.co.jp/site/cosmedecorte/c/c15/ (the canary URL): API HTTP 200, upstream status 200 (int, handed onward), 90,835 bytes, $0.0005; detect_page_state → content, 24 rows parsed.

Not changed, noticed in passing: python3 smoke_test.py -v (verbose) raises TypeError in 10 checks on origin/main too — the verbose branch of check() concatenates a non-string detail. The default, non-verbose run (what CI runs) is unaffected. Left for a separate fix. No version bump; entry under [Unreleased].

🤖 Generated with Claude Code