docs: fix non-claims the OLMo work made false

The scope section still said there was no OpenAI-compatible serving of real
weights, which the opening of the same README now disproves. A reader would
reasonably conclude nobody checked.

It now says what is actually true. Real weights are served over an OpenAI-shaped
endpoint, one request at a time, with no batching, no scheduling, no
multi-tenancy and no auth, because the KV cache holds one sequence.

The reduced-scale claim was also ambiguous once two model paths exist, so it now
separates them. OLMo runs full depth and full vocabulary from a real checkpoint.
The Qwen path is a synthetic-weight proof at reduced scale and says so.

Adds two claims that were missing rather than wrong. FP4 KV output is coherent
but unmeasured against an FP16 baseline. Performance is unoptimised, at about
125 ms/token with a host round trip per layer.

Also replaces an 'as above' that no longer referred to anything.

Author: maincode-dave

README.md

@@ -534,8 +534,12 @@ just check-model-api
 
 The numbers above are easy to over-read, so here's where the edges actually are.
 
-**This isn't a production serving stack.** No OpenAI-compatible serving of real
-weights, no continuous batching, no multi-tenant scheduling, no auth or quota.
+**This isn't a production serving stack.** It does serve real weights over an
+OpenAI-shaped endpoint, which is the whole point of the OLMo work, but it serves
+exactly one request at a time. There's no batching, no continuous batching, no
+scheduling across sequences, no multi-tenancy, no auth and no quota. The KV cache
+holds one sequence, so a second concurrent request waits. That's honest for what
+this is and it is nowhere near what a production server does.
 
 **`just demo` on its own is still synthetic.** It serves a real HTTP seam, and on
 hardware there's real GPU work behind it, but the text coming back is scripted.
@@ -544,11 +548,17 @@ endpoint serves real completions instead. `/v1/models` and `/api/health` both
 report `synthetic: false` when that's true, so a client can tell the two apart
 without reading the source.
 
-**The model loop runs at reduced scale.** Real head geometry and real per-op
-math, with reduced depth, vocabulary and expert count. It isn't a 94-layer,
-full-vocabulary, real-checkpoint proof.
+**Two model paths, and only one of them is real.** OLMo 2 runs at full depth and
+full vocabulary from a real checkpoint. The Qwen3-235B-A22B path
+(`mainarch model-decode`) is a synthetic-weight proof at reduced depth,
+vocabulary and expert count, keeping the real head geometry and per-op math. It
+demonstrates that the primitives compose into a working token loop. It is not a
+94-layer real-checkpoint Qwen.
 
-**The model API doesn't execute.** As above.
+**The model API doesn't execute.** `mainarch-core::model_api` compiles and
+validates model definitions and emits fingerprinted receipts. It does not lower
+a graph into AQL, allocate buffers or submit queues, and its own receipts assert
+`launch_executable: ready=false`. The OLMo path does not go through it.
 
 **The numbers come from a single host.** One machine with 8 MI355X cards, one
 software version. They're reproducible with the commands given, on that hardware.
@@ -557,7 +567,14 @@ software version. They're reproducible with the commands given, on that hardware
 table.
 
 **FP4 accuracy is an open question.** Around 15% rel-L2 raw on the primitive, and
-what that costs a real model isn't measured here.
+what that costs a real model isn't measured here. OLMo runs on FP4 KV today and
+its output is coherent, but coherent is not the same as measured, and no
+benchmark has been run against an FP16 baseline.
+
+**Performance is unoptimised.** About 125 ms/token for a 1B model. Nothing on
+the OLMo path is fused, batched or tuned, there's a host round trip per layer,
+and prefill costs one decode step per prompt token. The roadmap lists what would
+change that.
 
 **MI355X and gfx950 only.** See `docs/hardware-support.md`.