fix(lm-studio): recognize wrapped HTTP 400 grammar parse failures

[bestail]

Summary

• recognize LM Studio / llama.cpp sampler failures containing failed to parse grammar
• handle SDK wrappers that expose HTTP 400 only inside the exception message as predict request returned 400
• route both forms through the existing llama_cpp_grammar_pattern recovery path
• verify the complete recovery flow strips unsupported JSON Schema pattern / format keys and retries once

Problem

LM Studio can surface llama.cpp JSON-schema-to-grammar failures in either of these forms:

Failed to initialize samplers: failed to parse grammar

or, after SDK wrapping:

Engine protocol predict request returned 400:
{"error":{"code":400,"message":"Failed to initialize samplers: failed to parse grammar","type":"invalid_request_error"}}

The second form has no structured status_code, so Hermes currently classifies it as unknown. The first form has HTTP 400 but does not match the phrases recognized by the existing llama.cpp grammar recovery classifier. As a result, Hermes performs a generic retry without removing unsupported schema constraints, and the same request can fail again.

Root cause

The existing classifier recognizes:

• error parsing grammar
• json-schema-to-grammar
• unable to generate parser ... template

It does not recognize LM Studio's failed to parse grammar wording. It also requires a structured HTTP 400 status, while LM Studio's SDK wrapper may expose 400 only in the exception text.

Fix

Extend the existing llama.cpp grammar condition to accept:

1. structured status_code == 400, or
2. status_code is None when the normalized message contains predict request returned 400

and recognize failed to parse grammar as another llama.cpp grammar failure phrase.

The condition still requires a recognized grammar-specific phrase, so unrelated wrapped HTTP 400 errors are not routed into schema recovery.

Test plan

RED was observed before changing production code:

• the structured LM Studio sampler error was classified as format_error
• the SDK-wrapped error was classified as unknown
• the end-to-end retry did not strip pattern and format

GREEN after rebasing onto the latest origin/main and rerunning the combined relevant suites:

python -m pytest \
  tests/agent/test_error_classifier.py \
  tests/run_agent/test_run_agent.py \
  -q -n 0
647 passed in 108.38s

python -m compileall -q \
  agent/error_classifier.py \
  tests/agent/test_error_classifier.py \
  tests/run_agent/test_run_agent.py

Additional checks:

• rebased/fast-forwarded to current origin/main (95a566b1e769cca26dfa441c1ff963ec03bdc7d6) before final verification
• git diff --check passed
• static added-line security scan found no concerns
• independent code review: PASS, with no blocking security, logic, or compatibility issues
• no credentials, configuration, or provider-specific secrets are added

Scope and risk

The production change is limited to one existing error-classification branch. Cloud-provider behavior is unchanged unless an error simultaneously contains a recognized llama.cpp grammar phrase and either a structured HTTP 400 or LM Studio's wrapped predict request returned 400 marker.

[alt-glitch]

This was generated by AI during triage.

Duplicate of #67349: both patches recognize LM Studio's wrapped/status-less failed to parse grammar response and route it to the existing grammar-recovery path. #67349 also covers the broader sanitizer work.