ci(triage): catch a malformed credential, not just a revoked one

The token was replaced at 08:25 and the runs at 08:26 still failed — with a
different error, which this gate did not recognise:

  "Invalid auth token · Fix external auth token · Invalid Authorization header
   value from CLAUDE_CODE_OAUTH_TOKEN: it contains a line break at character 62
   (110 characters on 2 lines)."

  "error": "invalid_request", "api_error_status": null

No "authentication_failed", no 401 — so the gate added a few hours earlier
reported this as a generic workflow fault, which is exactly the unhelpful
message it existed to replace. Two shapes of the same problem inside a week:
revoked (401) and malformed (invalid_request, reason only in the message text).

Detection now also matches the text marker, but only on an object the SDK
itself flagged with is_api_error_message — an issue body that merely mentions
the secret's name cannot fake one, and a false positive would change only the
message since this branch exits 1 regardless.

The SDK's own wording is more useful than anything inferred here ("a line break
at character 62" names the exact defect), so it is now quoted verbatim in the
annotation, and the remedy says to re-enter the secret as a SINGLE line.

Verified against both real execution-file shapes captured from production —
today's malformed failure and the 08-30 revoked one — plus regression that
max_turns still escalates, generic failures keep the generic message, and an
issue mentioning CLAUDE_CODE_OAUTH_TOKEN is not misreported as a credential
fault.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.github/workflows/on_issues_ai_triage.yaml

@@ -362,6 +362,50 @@ jobs:
                "$EXECUTION_FILE" >/dev/null 2>&1
           }
 
+          # Did the run die because the Claude credential is bad? The action
+          # reports this uselessly — the failure surfaces as "--json-schema was
+          # provided but Claude did not return structured_output", which points
+          # at the schema and not at auth. The execution file carries the truth.
+          #
+          # A bad credential shows up in more than one shape, and both have been
+          # seen in production within a week:
+          #   * revoked token  -> error "authentication_failed", HTTP 401
+          #   * malformed token -> error "invalid_request", api_error_status
+          #     null, and the reason only in the SDK's message text ("Invalid
+          #     Authorization header value from CLAUDE_CODE_OAUTH_TOKEN: it
+          #     contains a line break at character 62").
+          # Matching only the first shape reported the second as a generic
+          # workflow fault, so the text marker is checked too — but only on an
+          # object the SDK itself flagged as an API error, so an issue body that
+          # merely mentions the secret's name cannot fake one. A false positive
+          # would change only the message: this branch exits 1 either way.
+          hit_auth_failure() {
+            [ -n "${EXECUTION_FILE:-}" ] && [ -s "${EXECUTION_FILE:-}" ] || return 1
+            jq -e '(type == "array") and
+                   any(.[]?;
+                       (type == "object") and
+                       (((.error? // "") == "authentication_failed") or
+                        ((.error_status? // 0) == 401) or
+                        ((.api_error_status? // 0) == 401) or
+                        (((.is_api_error_message? // false) == true) and
+                         (tostring | test("CLAUDE_CODE_OAUTH_TOKEN|Invalid auth token")))))' \
+               "$EXECUTION_FILE" >/dev/null 2>&1
+          }
+
+          # The SDK's own words are far more useful than anything this script
+          # can infer — "it contains a line break at character 62" names the
+          # exact defect. Surface it verbatim when present.
+          auth_failure_detail() {
+            [ -n "${EXECUTION_FILE:-}" ] && [ -s "${EXECUTION_FILE:-}" ] || return 0
+            jq -r 'if type == "array" then
+                     [ .[]? | select(type == "object")
+                            | select((.is_api_error_message? // false) == true)
+                            | tostring
+                            | capture("(?<m>Invalid Authorization header value[^\"]*|Invalid auth token[^\"]*)")
+                            | .m ] | first // ""
+                   else "" end' "$EXECUTION_FILE" 2> /dev/null || true
+          }
+
           # GATE 1 — did the action itself run? This is checked BEFORE looking
           # at the payload, because the action can fail *after* having written
           # a valid structured output: the object would sail through the shape
@@ -380,6 +424,17 @@ jobs:
           if [ "${CLASSIFY_OUTCOME:-}" = "failure" ]; then
             restore_needs_info
 
+            # Checked before anything else, because it is the one failure with
+            # a specific remedy and it takes down every tier at once — tier 1
+            # cannot label, so tier 2's batch is empty and the whole pipeline
+            # goes quiet while each run still fails in a way that reads like a
+            # per-issue problem. Say plainly what is wrong and what to do.
+            if hit_auth_failure; then
+              DETAIL=$(auth_failure_detail)
+              echo "::error::CLAUDE_CODE_OAUTH_TOKEN is being rejected${DETAIL:+ — $DETAIL}. This is NOT a problem with issue #$ISSUE: every AI workflow is down until the credential is fixed. Regenerate with 'claude setup-token' and re-enter the secret in the CR_PAT environment as a SINGLE line with no line break or trailing newline. Set the AI_DISABLED repo variable to 'true' to silence these runs meanwhile."
+              exit 1
+            fi
+
             # ...with one exception. Exhausting the turn budget is NOT a
             # workflow fault: the action ran fine and this particular issue was
             # just too tangled to finish inside the turn budget. Treating it as systemic