Scheduled canary run to detect NBS API breakage early

[chilango74]

Follow-up to #4 (item 4, left out of scope there).

Why

NBS reshuffled its API twice within two weeks (easyquery.htm retirement, then the getEsDataByCidAndDt → stream/esData rename). Both times the breakage was discovered days later by downstream nightly jobs (okama-scripts CNY.INFL failures), not by this library's own checks. A periodic integration run (NBSC_INTEGRATION=1 pytest) would surface a rename within a day, and since 1.1.0 the failure is self-describing (NbsEndpointError names every attempted URL).

Constraint (verified 2026-06-06)

NBS drops traffic from US datacenter IPs: requests via a US proxy egress time out, while an RU-hosted server reaches data.stats.gov.cn directly in ~1.6 s. GitHub-hosted Actions runners egress from US IPs, so a plain GHA cron workflow will not work.

Options

1. systemd timer on an RU-hosted server (e.g. the production host that already runs okama-scripts): weekly NBSC_INTEGRATION=1 pytest in a scratch venv, OnFailure= wired to the existing notify-email template. Network path verified; least moving parts. Recommended.
2. Self-hosted GitHub Actions runner on the same host: nicer CI surface (status badges, history), but a permanently-running agent to maintain.
3. GHA cron through a proxy with NBS-friendly egress: depends entirely on having a reliable non-US proxy; as of 2026-06-06 the available proxies are either down or US-based.

🤖 Generated with Claude Code