Add entry log to error_classifier.js classify function

[stranske]

Why

The classify() function in error_classifier.js processes error messages but lacks visibility into when classification starts. Adding an entry log helps trace error classification during CI failure debugging.

Scope

• Modify the classify() function in .github/scripts/error_classifier.js
• Add one console.log statement at function entry

Non-Goals

• No changes to classification logic
• No changes to test files
• No new dependencies

Tasks

• Add console.log at start of classify() showing error type being classified
• Verify existing tests pass

Acceptance Criteria

• classify() logs: [error_classifier] Classifying error: <first 50 chars>
• All existing tests in __tests__/error_classifier.test.js pass
• No lint errors

Implementation Notes

File: .github/scripts/error_classifier.js

Add at the start of the classify function:

console.log(`[error_classifier] Classifying error: ${(error || "").substring(0, 50)}`);

[github-actions]

🤖 Auto-pilot step 1: Starting issue formatting...

Adding agents:format label to trigger LangChain formatting.

[github-actions]

Branch codex/issue-755 created from main.

Option 1 (Invite) is enforced on issue events. PR creation is disabled by design so you are the PR author. Auto Pilot only engages on human-authored PRs.

Please open the PR as the author so Auto Pilot can work on it:

• Compare link: https://github.com/stranske/Workflows/compare/main...codex/issue-755?expand=1
• Suggested title: Auto Pilot bootstrap for #755
• Suggested body (copy/paste):

<!-- meta:issue:755 -->

@auto-pilot Your objective is to satisfy the **Acceptance Criteria** by completing each **Task** within the defined **Scope**.

## Keepalive Next Task

**This round you MUST:**
1. Implement actual code or test changes that advance at least one incomplete task toward acceptance.
2. Commit meaningful source code (.py, .yml, .js, etc.)—not just status/docs updates.
3. Mark a task checkbox complete ONLY after verifying the implementation works.
4. Focus on the FIRST unchecked task unless blocked, then move to the next.

**Guidelines:**
- Keep edits scoped to the current task rather than reshaping the entire PR.
- Use repository instructions, conventions, and tests to validate work.
- Prefer small, reviewable commits; leave clear notes when follow-up is required.
- Do NOT work on unrelated improvements until all PR tasks are complete.

**COVERAGE TASKS - SPECIAL RULES:**
If a task mentions "coverage" or a percentage target (e.g., "≥95%", "to 95%"), you MUST:
1. After adding tests, run TARGETED coverage verification to avoid timeouts:
   - For a specific script like `scripts/foo.py`, run:
     `pytest tests/scripts/test_foo.py --cov=scripts/foo --cov-report=term-missing -m "not slow"`
   - If no matching test file exists, run:
     `pytest tests/ --cov=scripts/foo --cov-report=term-missing -m "not slow" -x`
2. Find the specific script in the coverage output table
3. Verify the `Cover` column shows the target percentage or higher
4. Only mark the task complete if the actual coverage meets the target
5. If coverage is below target, add more tests until it meets the target

IMPORTANT: Always use `-m "not slow"` to skip slow integration tests that may timeout.
IMPORTANT: Use targeted `--cov=scripts/specific_module` instead of `--cov=scripts` for faster feedback.

A coverage task is NOT complete just because you added tests. It is complete ONLY when the coverage command output confirms the target is met.

**The Tasks and Acceptance Criteria are provided in the appendix below.** Work through them in order.

<!-- 
  DO NOT ADD TASK CONTENT BELOW THIS LINE
  
  Task content is dynamically injected from the PR body via the `appendix` input.
  This template file should only contain instructions, not PR-specific tasks.
  
  If you see task content in this file, it was incorrectly committed and should
  be removed. The guard script will flag this as an error.
-->

[github-actions]

🏷️ Label Suggestions

Based on the issue content, these labels might be relevant:

• feature (90% confidence)
• enhancement (90% confidence)
• bug (91% confidence)
• verify:evaluate (95% confidence)
• verify:create-issue (95% confidence)
• verify:compare (95% confidence)
• verify:checkbox (95% confidence)
• test (95% confidence)
• integration-test (95% confidence)
• integration-failure (95% confidence)
• github:actions (95% confidence)
• dependencies (95% confidence)
• ci-failure (95% confidence)

Auto-applied: ci

How to use these suggestions

• Click the label name in the sidebar to add it
• Or use the GitHub CLI: gh issue edit 755 --add-label "label-name"

---

Auto-generated by label matcher

[github-actions]

🤖 Auto-pilot step 1: Analyzing issue for improvements...

Adding agents:optimize label to trigger analysis.

[github-actions]

🤖 Auto-pilot step 1: Applying optimization suggestions...

Adding agents:apply-suggestions label.