MCP servers, over streamable HTTP

A server is a row with a URL; its tools are discovered by a button and
cached, then offered beside the built-in ones. Written by hand rather than
taken from the reference SDK, because that SDK's transport does its own
connecting -- and the one thing that must not be bypassed is check_url on
every hop. Owning the transport is the point; the framing beside it is the
small part.

Sessions are per call: initialize, initialized, the call, a best-effort
DELETE. Caching one wants an owner, a TTL, eviction, a lock and a shutdown
hook, and the server may expire it under all of that anyway -- ToolContext
is a session-free snapshot precisely so nothing in a tool holds live state.

A server's names and descriptions reach the model as instructions and are
bounded before they do; what it returns is escaped preformatted text, never
markdown. Tools are namespaced per server, so two servers exposing "search"
do not collide and neither shadows a built-in.

Also: a round's calls now run together under a semaphore, results indexed
so each tool turn stays paired with its call, and generation.status names
what is running -- a remote tool is latency-bound, and a silent pause is
what a hang looks like.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/lembas/web/templates/admin/_layout.html

@@ -47,6 +47,10 @@
           {{ icon("link", "icon--sm") }}
           <span class="nav-item__label">Tools</span>
         </a>
+        <a class="nav-item {{ 'is-active' if section == 'mcp' }}" href="/admin/mcp">
+          {{ icon("server", "icon--sm") }}
+          <span class="nav-item__label">MCP servers</span>
+        </a>
         <a class="nav-item {{ 'is-active' if section == 'prompts' }}" href="/admin/prompts">
           {{ icon("sparkle", "icon--sm") }}
           <span class="nav-item__label">Prompts</span>