fix(agent): classify OpenAI regex lookaround schema rejection as recoverable

[liuhao1024]

What does this PR do?

Classifies HTTP 400 errors from OpenAI-compatible endpoints that reject tool schemas containing regex lookaround patterns as recoverable, routing them through the existing strip_pattern_and_format() retry path so the conversation continues instead of failing permanently.

Related Issue

Fixes #42631

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• agent/error_classifier.py: Extended the llama.cpp grammar-pattern condition to also match OpenAI-compatible "regex lookaround is not supported" errors, routing them through the same FailoverReason.llama_cpp_grammar_pattern recovery path
• tests/agent/test_error_classifier.py: Added 2 tests — one verifying the lookaround error is classified as retryable, one verifying partial keyword matches don't trigger false positives

How to Test

1. Run pytest tests/agent/test_error_classifier.py -q — all 157 tests pass (including the 2 new ones)
2. Run pytest tests/tools/test_schema_sanitizer.py -q — all 40 schema sanitizer tests pass (verifies the downstream recovery path)
3. The new test_openai_regex_lookaround_rejection test verifies the exact error message from the issue is classified as FailoverReason.llama_cpp_grammar_pattern with retryable=True

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Code Intelligence

• Analyzed: agent/error_classifier.py (error classification logic), agent/conversation_loop.py:2304 (recovery path consumer), tools/schema_sanitizer.py:308 (strip_pattern_and_format)
• Blast radius: LOW — only affects HTTP 400 errors with specific regex lookaround phrasing; all existing llama.cpp grammar tests unchanged
• Related patterns: Existing llama_cpp_grammar_pattern recovery path at lines 606-621; this extends the same condition with an additional disjunct

[teknium1]

Thanks for the focused compatibility recovery. Current main still classifies only llama.cpp grammar-parser phrases at agent/error_classifier.py:698-713; the reported lookaround 400 therefore reaches generic non-retryable 4xx handling. The added condition maps that exact error family to the established one-shot strip_pattern_and_format(agent.tools) recovery at agent/conversation_loop.py:2940-2964.

The focused classifier tests are appropriate for the new recognition branch, and the existing recovery path preserves its no-op/fall-through guard when no compatible schema keyword exists to strip.

Automated hermes-sweeper review.

[mvdbastos]

We're pulling #67349 into our fork for a related llama.cpp/LM Studio grammar-phrase gap (same error_classifier.py condition, same recovery path). Flagging so the two don't collide — this PR and #67349 both add disjuncts to the same llama_cpp_grammar_pattern branch, worth reviewing together to avoid duplicate/overlapping matches. Happy to help reconcile if that's useful.