v0.1.3 — audit fixes

An audit against this family's own checklist, run after publishing
rather than before it. Everything here was found by a check or a live run,
not by reading.

Fixed

scraper_api_client.py reported an upstream failure as an empty board.
It did not consult page_flow.should_parse() the way the three browser
engines do, so a body the site never served came back as Parsed 0 job(s)
and exit 4 — "the query matched nothing". It now names the state, saves
the body and exits 5. Blocked, empty and failed are three different
answers.

A latent NameError in the same client — EXIT_NO_PRODUCTS used on
the new not_found branch and never imported. Caught by the suite's
undefined-name walk, and the control was verified: planting the fault makes
the check name that exact symbol.

--url was validated against HOST while HOSTS sat unread. The
tuple is the single source of truth now rather than decoration.

Corrected

The README had the Scraper API backwards. It said the service suits the
rendered listing page better than the endpoint — reasoned, not measured.
Measured 2026-09-18:

--url	result
/api/candidate-api/offers?… (47 KB)	HTTP 200 in 12s, 20 rows, $0.0005
/job-offers/all-locations (1.8 MB)	HTTP 408 at the default 60s
the same page at --timeout 120	API 200, upstream HTTP 500, 0 bytes

Point it at the endpoint.

An inherited figure replaced with a measured one. A comment repeated a
"17 of 18 repos" count for the fingerprint flags. Re-counted across the 26
siblings: 25 of 26 — with the command beside it, so the next reader
re-measures instead of inheriting.

Verified live, with a real 2Captcha key

• --fingerprint applies what it fetches. Four defects have shipped on
  this path across this family; none is present here. A PL fingerprint
  reached the browser intact — user agent Windows NT 10.0 … Chrome/151,
  locale pl-PL (not en-PL), timezone Europe/Warsaw — and
  --fp-tags Windows is accepted by the API.
• Credentials never reach a log, including an exception message. A dead
  proxy carrying secretuser:secretpass123 logged
  http://***:***@127.0.0.1:9 — host and port kept, both credentials
  masked, zero occurrences of either anywhere in the run — and was named a
  proxy failure rather than a timeout. Identical on all three engines.

597 offline checks, up from 591.