Five fixes, two of them reported from production in the same hour.

EMPTY REPLIES from a chat naming `diogene-alpha`, while `qwen38` — the same
weights on the same pod — answered normally. Parser selection reads the model
NAME:

    if 'qwen' in model_lower:  -> QwenParser

`qwen38-awq` matches; `diogene-alpha` matches nothing and fell to the generic
parser, so the model's <think>…</think> block was never separated from the
answer. With a modest max_tokens the whole budget goes into reasoning that
never closes, and the caller sees an empty reply from a 200 — the hardest kind
of wrong to see. A LoRA is named for what it was trained to do; it is the same
FAMILY as the weights it adapts, so a name matching nothing now resolves to the
base's. Nothing is discarded: the thinking comes back as `reasoning` and
`reasoning_content`, as it always did for the base.

This also corrects a reading of my own: every temperature-0 comparison in this
chain showed the adapter leaking its reasoning while the base answered cleanly,
and I took that as evidence the adapter was not loading. It was the parser.

/v1/chunk with X-Coderai-Placement: remote answered 502 "nothing configures
'embeddings' to run remotely" while a coderai-embeddings pod — which has the
chunker in it — sat there serving bge-m3. A capability-only request names no
model, so the per-model placement that moved everything else cannot place it.
It now borrows the destination of a model OF THE SAME CAPABILITY that is
already remote. Same capability only (an embeddings pod has no OCR deps), and
only on an explicit `remote`: nothing should rent a GPU to run a regex split
because nobody said otherwise.

Registering an adapter is not serving it. vLLM takes its adapters at launch and
the code that adds one to a live engine sits on the model-LOAD path, which does
not run again for a model this instance already loaded. So a pod could be sent
an adapter, register it, report it in /v1/loras and go on answering from the
base. Registration now hands it to the running engine, swapping a stale one.

A stale content id repairs itself. v0.3.94 fixed what new uploads are stored
as; an entry already registered under a non-canonical id stayed broken with no
symptom but base-model answers. Seeding and pushing resolve an id against the
CONTENT first.

And `it-legal` now sets min_chunk_chars: 300 (strict stays 0) — it is the
OCR-aware template, so it meets short trailing sections more often, and a
56-character chunk is too small to carry meaning and long enough to match. A
runt folds only into a chunk that can CARRY it, so a document of short sections
stays several chunks instead of collapsing. Absorption may never cross
conclusioni <-> dispositivo at any size: what a party asked for and what the
court decided, and a recorded label is a weaker guarantee than refusing the
merge.

NOTE: this release MOVES CHUNK BOUNDARIES for anyone using `it-legal`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM