Run every qsv call through qsv-client

[jqnatividad]

Why

No qsv run during onboarding had a timeout. A stalled describegpt (an LLM that never answers) or a stats --everything on a huge CSV blocked the job forever. qsv-client kills a run's whole process group once it passes its timeout. It also returns typed errors and finds the binary in one place.

What changed

• Timeouts per pass: describegpt 900 s, stats 900 s, frequency 600 s, count 120 s. Each one can be overridden with VERIKAN_QSV_<PASS>_TIMEOUT, e.g. VERIKAN_QSV_STATS_TIMEOUT=1800.
• Same failure contract: run_qsv_describegpt / run_qsv_stats / run_qsv_frequency still return None on failure, now including a missing binary or a timeout. They log the error type and kind instead of truncated stderr.
• No truncated outputs: stats and frequency stream to a sibling .part file that replaces the output only when the run succeeds. A failed run leaves the previous qsv_stats.csv / qsv_frequency.csv in place. The bytes on disk are still exactly qsv's stdout.
• qsv_dict.json unchanged: it is still re-dumped with json.dump(indent=2), because it is published and hashed.
• Binary discovery honours QSV_BIN, in the admin health warning too. Discovery can fall back to qsvlite/qsvdp, which have no describegpt. So after a describegpt failure the binary's command list is checked once, and a missing describegpt is reported.
• run_qsv_count replaces the duplicated inline qsv count blocks in both onboarding scripts, which swallowed every exception.
• Dockerfile moves from qsv 22.0.1 to 24.0.0. The release zip still has qsv at its root.

Tests

New fake-binary tests cover:

• stats output bytes and parsing
• frequency parsing
• a failed run keeping the previous output
• a hung run being killed, with the child process gone
• count
• a missing binary
• a binary without describegpt

runtime_warnings is now tested via QSV_BIN. I broke each fix in turn and the matching test failed each time.

I also smoke-tested against a real qsv 24.0.0.

🤖 Generated with Claude Code