fix(llm): let a model refuse temperature, and say which extractor is installed

Two reports, both about an import that fails without saying why.

#2262 — temperature: 0 sat in the shared request body, so it went out on every
attempt including both retries. Reasoning models (the gpt-5 family) reject any
explicit temperature, and the json_object retry fires on any 400, so the import
spent two doomed requests and could not succeed at all. The parameter is now
dropped once a server has explicitly said it will not take it.

Not as a third link in the chain, though. A gpt-5 rejects max_tokens AND
temperature, the API names one parameter per response, and it may name either
first — a chain of one-shot ifs converges on only one of the two orders. The
retries are a loop over what the server actually said instead: each remedy
applies at most once and they compose. Detection is a phrase, not the bare word,
because dropping temperature costs the deterministic sampling that small local
models depend on, and an unfamiliar wording still falls through to the
json_object retry exactly as before. NuExtract and Ollama are untouched: the
first attempt always carries temperature, and it is the only one they ever see.

#2261 — the bundled extractor is Debian trixie's 24.12.3, roughly eighteen
months behind upstream, and the reporter is right that this is invisible: a
stale extractor, a mistyped KITINERARY_EXTRACTOR_PATH and a genuinely
unsupported provider all look the same from the UI, which is nothing imported
and no reason given. The version now appears in the startup log and in a new
admin-only GET /api/admin/system-info, and LOG_LEVEL=debug passes the
extractor's raw stderr through — the JS ERROR and Invalid-result-type lines the
filter drops are the only evidence that a vendor script is missing or failing.
Capped at 200 lines, and opt-in because those lines can carry document
fragments.

Not bumping the package: the filter the reporter needs first ships in KDE Gear
26.08 and no Debian suite carries it, and sid's 26.04.3 wants KF6 6.22 and Qt6
6.10.2 against trixie's 6.6 and 6.8.2 — a partial upgrade of Qt6, KF6 and libc6
from unstable into the production image, on two architectures, that still would
not fix the reported carrier. It comes for free with the base-image move after
Debian 14.

wiki/Environment-Variables.md

@@ -269,7 +269,12 @@ Request bodies validated with Zod are documented automatically from the same sch
 The official TREK Docker image bundles the binary automatically: on both amd64 and arm64 it installs
 `libkitinerary-bin` via apt (Debian trixie) and symlinks it to `/usr/local/bin/kitinerary-extractor`, which the image
 also pins via `KITINERARY_EXTRACTOR_PATH`. When running TREK from source, install `libkitinerary-bin` (Debian trixie /
-Ubuntu 25.04+) or download the static binary directly and place it anywhere on `PATH`. The
+Ubuntu 25.04+). There is no static binary to download; to run a newer extractor than your distribution
+packages, build one and point `KITINERARY_EXTRACTOR_PATH` at it, or derive an image from the official one with your own
+apt sources. The extractor's version is in the startup log and in `GET /api/admin/system-info` (admin only) — worth
+checking before reporting that a provider is unsupported, since a missing vendor script and an unsupported provider
+both come back empty. `LOG_LEVEL=debug` additionally passes the extractor's raw stderr through, including the
+`JS ERROR` lines that name a failing script; it is read once at startup, so it needs a restart. The
 `GET /api/health/features` endpoint returns `{ "bookingImport": true }` when the binary is found. The Import button in
 the Reservations panel is hidden only when **neither** extractor is available — an instance running the AI Parsing
 addon still offers it with `bookingImport: false`.