/v1/chat/completions accepts response_format with type: "json_schema" and strict: true, returns 200, but the assistant content does not follow the schema. The request looks honored when it isn't, so a client has no way to tell that the output is unconstrained.

Root cause

response_format is only schema-enforced when a grammar compiler is available. _compile_grammar_for_request (server.py) reads engine.grammar_compiler; when that is None (no xgrammar installed, or an engine that never installs one such as DFlash), or when grammar compilation raises, the request silently falls back to prompt injection (server.py:2233). The model is asked to produce JSON in the prompt, but nothing constrains decoding, so undeclared fields appear, required fields are dropped, and on larger inputs the content stops being valid JSON. structured_outputs already returns a 400 in this case; response_format was the silent path.

Fix

The reporter asked for one of two things: enforce the schema, or signal that it wasn't. Enforcing on every engine is a larger change (it needs grammar wiring on engines that don't have a compiler at all). This PR does the signal, on both surfaces:

• Operator-visible log. The fallback now logs a warning instead of degrading silently. A strict: true request gets a message that names the unhonored strict intent.
• Client-visible header. The response carries an RFC 7234 Warning header (code 199) on both the streaming and non-streaming paths so the caller can detect the degrade without parsing the body. strict requests get a header that says the output is NOT schema-enforced; non-strict response_format requests get a generic one.

The request still returns 200 with best-effort content. I chose not to turn an accepted request into a 400. That is a breaking behavior change, and neither I nor the reporter owns this repo. If maintainers prefer a hard reject, the strict-detection helper (_response_format_requests_strict) is the single place to branch on.

Scope

This addresses /v1/chat/completions, which is what the issue reports. /v1/completions and /v1/messages share _compile_grammar_for_request, so they get the warning log, but not the header. Extending the header to those endpoints is a separate change. Actually enforcing the schema on compiler-less engines (the other half of the reporter's ask) is also separate.

Evidence

Live-tested against a DFlash model (Qwen3.6-27B-4bit), which has no grammar compiler, so every response_format request hits the fallback.

Strict json_schema, non-streaming. The body reproduces the bug from the issue (src instead of dst), and the header now flags it:

HTTP/1.1 200 OK
warning: 199 omlx "response_format strict json_schema not enforced; grammar-constrained decoding unavailable, output is best-effort and NOT schema-enforced"
content-type: application/json

{"choices":[{"message":{"role":"assistant","content":"{\"items\": [{\"id\": \"1\", \"src\": \"Hello.\"}]}"},"finish_reason":"stop"}], ...}

Strict json_schema, streaming (stream: true). Same header on the SSE response:

HTTP/1.1 200 OK
content-type: text/event-stream
warning: 199 omlx "response_format strict json_schema not enforced; grammar-constrained decoding unavailable, output is best-effort and NOT schema-enforced"

Non-strict json_object. Generic header, no strict wording:

HTTP/1.1 200 OK
warning: 199 omlx "response_format not enforced; grammar-constrained decoding unavailable, output is best-effort"

No response_format (control). No Warning header:

HTTP/1.1 200 OK
content-type: application/json

Unit tests: tests/test_grammar.py covers the strict-detection helper, the degrade-not-raise behavior, and the header text (strict vs generic, single-line ASCII). Full grammar suite is green (72 passed, 3 skipped, the skips are pre-existing).

Fixes #1241