Detect and log JavaScript/bot challenges in the SUMO fetch scripts

Problem

The two fetch scripts pull JSON from support.mozilla.org/api/2/... through the shared getKitsuneResponse helper. If SUMO ever sits behind a JavaScript/bot challenge (Cloudflare "Just a moment…", /cdn-cgi/challenge-platform/, "enable JavaScript and cookies to continue", etc.), the endpoint returns an HTML page instead of JSON.

Today that path is silent and misleading:

• JSON.parse(result.body) raises JSON::ParserError
• it is retried 3× (pointless — re-requesting the same URL re-serves the same challenge), then getKitsuneResponse returns nil
• callers treat nil as "no data for this window" → they write an empty CSV (or skip a question's answers) and the run looks like a normal quiet day

So a challenge is indistinguishable from a genuinely empty result.

Goal

Detect challenge responses, log them to a dedicated auditable file (plus STDERR), and abort the day's run with a non-zero exit so the failure is visible rather than masquerading as empty data.

Implementation (done in da6ea03074)

get-kitsune-response.rb (only place with access to result.body + headers):

• Added a JavascriptChallengeError class carrying url, response_code, body snippet.
• Added a javascript_challenge?(body, content_type) detector matching well-known markers (just a moment, cdn-cgi/challenge-platform, cf-browser-verification, _cf_chl_opt, checking your browser, enable javascript and cookies, etc.), with HTML content-type + <noscript>/challenge as a corroborating signal.
• Added a shared log_javascript_challenge(logger, error, context) writer that appends one line to javascript-challenges.log (resolved via __dir__ so it always lands at repo root regardless of cwd) and mirrors to logger.error.
• In rescue JSON::ParserError, checks for a challenge first and raises JavascriptChallengeError instead of pointlessly retrying-then-returning-nil.

get-tb-creator-answers-questions-for-arbitrary-time-period.rb and get-tb-answers-from-questions-file-for-arbitrary-time-period.rb:

• Wrapped the fetch loop in rescue JavascriptChallengeError => e → log_javascript_challenge(...) then exit 1.
• Genuine per-question nil misses keep their current "log + continue" behavior; only an actual challenge aborts.

Follow-ups

• No new dependencies (stdlib File/Time + existing Typhoeus result.headers).
• Decide whether javascript-challenges.log should be committed for audit (and if so confirm the GitHub Actions workflows stage it) or .gitignored (Actions-log only).

Review get-kitsune-response.rb and the two named fetch scripts first; inspect commit da6ea03074 and the GitHub Actions workflows to understand where javascript-challenges.log is expected to go. Done means resolving whether the log is committed or ignored and confirming the workflows preserve the chosen audit behavior; the challenge handling itself is described as implemented.