fix(retain): constrain occurred_start/occurred_end so grammar-constrained models can't emit prose

[nickanderson]

Problem

occurred_start and occurred_end are LLM-facing fields typed as bare
str | None, so the generated JSON schema advertises "any string". Their
descriptions say "ISO timestamp", but under grammar-constrained decoding
(response_format: json_schema → GBNF) a description is not a constraint —
the grammar is the only thing standing between the model and an arbitrary
string.

When the model is asked for a timestamp it cannot derive — e.g. a narrative
duration with no start time — it reasons inside the string value:

"occurred_start": "2026-08-20T00:00:00Z/N/A (duration 40 mins implied within the
 incident window, but specific start time not provided, using event date as
 reference) -> 2026-08-20/2026-08-20 ... Actually, I will use ... Wait, the prompt says "

Two failures from one root cause:

1. Corrupted record — a stored fact whose occurred_start is a paragraph of
   the model's reasoning rather than a date.
2. Runaway generation — it doesn't stop. Observed runs burned the entire
   completion budget (2500/2500, and 4,598+ tokens on a larger cap) producing an
   unterminated JSON body with finish_reason: "length", which the retain path
   then re-sends byte-identical. That is the failure class described in finish_reason: "length" on the non-streaming .create() path is treated as a parse error, not OutputTooLongError — the fact-extraction auto-split (#2579/#3174) is still dead code for the truncation subclass #3811
   and openai_compatible_llm: bare json.loads + identical retries — parse_llm_json/json_repair never reached, deterministic failures burn all 4 attempts and drop the chunk #3683; this PR removes one of its triggers.

Reproduced with gemma-4-26B-A4B-it (Q4, Q6 and Q8) w/ llama.cpp.

Field emission order is significant here and is not always the client's to control. llama.cpp compiles properties into the grammar in order and enforces it.
re-serializes the request body with a sorted-map JSON type silently alphabetizes properties — which puts occurred_end/occurred_start ahead of
what — and the client cannot detect this, because the schema is still ==
equal as an object. (I hit this with one such proxy.
this PR fixes the symptom.)

[strix-security]

Strix Security Review

Warning

This pull request has 30 commits after the last Strix review (6772cb3). Strix has not reviewed these changes.
Automatic review on push is off for this repository. To review the latest changes, tag @strix-security in a comment, or turn on re-review on push.

No security issues found.

_{Updated for 6772cb3.}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}