Harness spec 3.0.0-draft: link protocol 3; one server names the models

acp.md *Versions*: LLeMbas 2.0 and LLeMbas CLI 2.0 speak link protocol 3 and
nothing else, so a 1.x peer and a 2.0 one refuse each other and each says what
to update. A 2.0 server's discovery says `protocol: 3, protocols: [3]` —
`protocol` was frozen at 1 so 1.x clients comparing it could log in; raising
it now is the point. A 2.0 CLI logs in and links only where 3 is listed and
otherwise names the server's version and protocols; a 2.0 server closes a
hello of 1 or 2 with 4400 and "update LLeMbas CLI to 2.0".

Model naming: the served id is the device's ref (one server, no connection
prefix, no second login); the older forms still resolve. A configure naming a
model the device cannot run is -32602 too, and the session keeps its model.
initialize's example says 3; `show` in the client's capabilities.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

harness/README.md

@@ -108,7 +108,10 @@ this design.
   answer with their diff; the same listing or search with the same result is a stub; compaction
   adds a table of reads and empties the dedupe table; earlier reasoning is left to the chat
   template. `loop.json` `context` holds the texts and numbers, `blocks/context.md` tells the model.
-- **`acp.md`**: `session/new`'s result carries `instance`; a session the client opened runs on the
+- **`acp.md`**: **link protocol 3** — LLeMbas 2.0 and LLeMbas CLI 2.0 speak it alone, and a 1.x peer
+  and a 2.0 one refuse each other, each saying what to update (discovery's `protocol` is raised to 3
+  on purpose); the served id is the device's ref for a model (one server, no connection prefix);
+  `session/new`'s result carries `instance`; a session the client opened runs on the
   chat's model and no other — refused rather than answered on the device's own, so the "answered on
   its own model" notice is gone; capability `show` with `_lembas/show`; memory through the
   instance; a 3.0.0 instance sends neither `library` nor `prototypes`.