fix(cron): prevent false-positive 401/403 match in no_agent script stdout (#70908)

[webtecnica]

What

_summarize_cron_failure_for_delivery() previously matched bare 401/403 anywhere in the error text via \b(401|403)\b. This caused misleading "provider authentication error" notifications when:

1. A no_agent=True cron job's script exits non-zero (no provider involved at all)
2. The script's stdout contains 401 or 403 in any context (e.g., test output like "returns 401 on invalid input")
3. The actual failure is unrelated

Fix

Two layered guards:

1. no_agent check — Skip the entire auth-detection block when job.get("no_agent") is truthy. A no_agent job has no LLM provider involved, so a provider auth error is impossible regardless of what the script printed to stdout.

2. Tighter HTTP context regex — The 401/403 status code detection now requires an HTTP context prefix (HTTP/, status , or response ) instead of matching bare numbers anywhere. This prevents false matches from digits appearing coincidentally in test output or other script stdout.

Testing

Added 14 tests covering:

• no_agent=True: 401 in output -> NOT auth error, 403 in output -> NOT auth error, "authorization" keyword -> NOT auth error
• HTTP context matches: HTTP/1.1 401, HTTP/2 403, status 401, status 403, response 401 -> all match auth error
• Keyword matches: "Authentication", "Authorization" -> match auth error (unchanged)
• Bare numbers: bare "401" / "403" without HTTP context -> NOT auth error
• Non-regression: rate limit and timeout detection still work (unaffected)

[teknium1]

Thanks for addressing a real delivery-classification bug: current main still treats any bare 401 or 403 as provider authentication at cron/scheduler.py:128, and failed no_agent script output reaches this summarizer through cron/scheduler.py:2776-2841 and cron/scheduler.py:3989.

Problems

• cron/scheduler.py:137 changes the status predicate to [45]\d\d, which matches every 4xx/5xx response. Thus HTTP/1.1 404 and response 500 would be delivered as "provider authentication error," contrary to the stated 401/403-only behavior.

Suggested changes

• Restrict the new HTTP-context branch to exact 401/403 status codes.
• Add negative tests for contextual 404 and 500 responses; the current added tests cover only 401/403 positives and bare-number negatives.

Automated hermes-sweeper review.

[teknium1]

[45]\d\d matches every 4xx/5xx code, so HTTP/1.1 404 and response 500 take the provider-authentication branch. Please restrict this alternative to exact 401/403 codes and add contextual 404/500 negative coverage.

[teknium1]

Closing with credit — the motivating bug (#70908, bare 401/403 tokens in no_agent script stdout tripping a provider-auth alert) is fixed on main via PR #85536: no_agent jobs are now excluded from ALL provider-shaped classification (rate-limit, timeout, auth), which covers your case. Your HTTP-status-context refinement for agent-mode jobs is a reasonable further hardening — if you'd like to rebase just that half onto current main as a small follow-up, we'd review it. Thanks!