docs(server): lora_adapter is documented as a request field but implemented nowhere

[jamesburton]

Observation

Found while addressing review feedback on #326.

docs/SERVER.md:32 documents a lora_adapter request field. Grep puts it nowhere in
src/DotLLM.Server/ — not in the Anthropic DTOs, and not in the OpenAI ones either. The doc frames
it as parity with the OpenAI surface, so the claim is wrong twice over: the field is unimplemented,
and the surface it claims parity with does not have it.

A user sending lora_adapter today gets it silently ignored, with no error and no effect — the
worst outcome for a field that appears in the documentation.

LoRA is not implemented anywhere in the server. Across the tree it exists only as
src/DotLLM.Engine/IAdapterManager.cs — an interface with no implementations and no references —
plus InferenceRequest.AdapterId. It is roadmap step 47, unstarted. (An earlier revision of this
issue claimed a registry and admin endpoints existed; that was wrong, and corrected here.)

Options

Either is fine, but the current state should not persist:

1. Remove it from the docs and note that per-request adapter selection is not yet supported,
   pointing at the admin endpoints for what does work. Smallest, honest.
2. Implement it — wire the field through the request DTOs to adapter selection. Larger, and
   wants its own design discussion about precedence when an adapter is also set server-side.

I would do (1) now and open (2) separately if per-request selection is wanted, so the docs stop
describing something that does not exist in the meantime.

Acceptance criteria

• docs/SERVER.md no longer documents a request field that does not exist, or the field is
  implemented and covered by a test.
• If removed, the doc says what to use instead for adapter selection.
• If implemented, an unknown adapter name produces a well-shaped error rather than being ignored.

References

• server: Anthropic-compatible Messages API (/v1/messages) (#325) #326 — removed the same stale field from the new /v1/messages example; this issue covers
  docs/SERVER.md, which that PR does not touch

[jamesburton]

Correcting an error in my own issue text, since it would have sent someone the wrong way.

I wrote that "LoRA adapters are real in the engine (there is a registry and admin endpoints); it is
the per-request field that does not exist." That is wrong. grep -i lora src/DotLLM.Server/
returns nothing at all, and across the whole tree LoRA exists only as
src/DotLLM.Engine/IAdapterManager.cs — an interface with zero implementations and zero references —
plus InferenceRequest.AdapterId. It is roadmap step 47, unstarted. The issue body is corrected.

This matters for the fix: pointing the docs at "the admin endpoints" was not possible, because there
are none. PR #427 instead points at the real workaround — merge the adapter offline and load the
merged model via --model (ServerOptions.cs:89) or POST /v1/models/load
(ModelManagementEndpoint.cs:29), both verified to exist.

It also turned up a second stale claim that the original issue missed: docs/LORA.md's "Runtime
Application" section states "Each request specifies lora_adapter" — the exact claim SERVER.md now
retracts. #427 labels that document as a design spec so the two stop contradicting each other. The
remaining lora mentions in ROADMAP/ARCHITECTURE/AOT all describe the planned feature and remain
accurate.