Let agents drive the flow API over MCP

The engine now speaks MCP at /mcp, with a built-in OAuth 2.1 authorization
server in front of it: an agent registers itself, sends a human to the browser
to approve it, and exchanges the resulting code for a token. PKCE is required,
codes are single-use and stored only as hashes, the browser is redirected to
the URI that was registered rather than the one asked for, and refresh tokens
rotate so that replaying a spent one revokes the whole line.

Twenty tools cover reading, building, publishing and running flows, and each
one calls the same REST endpoint the dashboard calls, in-process, carrying the
caller's own token. That keeps one description of what a flow is and what may
be done to it — validation, the draft/publish split, the version check — and
means an agent can do nothing a person could not do in the browser.

Agent tokens are RS256 with a keypair of their own rather than the secret that
signs browser sessions, so deleting the key withdraws every agent without
logging anyone out, and deps.decode_token grew the branch that trusting a
second issuer will need when the hosted login arrives.

ROADMAP.md

@@ -75,7 +75,13 @@ external interfaces. See `docs/architecture/structure.canvas` → *Backend – M
 - [ ] Test nodes: a small node dragged onto an existing one, smoke or unit, blocking
       deployment on failure
 - [ ] User management scoped per flow and per data set
-- [ ] LLM interface for natural-language flow authoring
+- [x] MCP server over the same API: agents authenticate through a built-in
+      OAuth 2.1 authorization server (dynamic registration, PKCE, rotating
+      refresh tokens) and drive the flow API through 20 tools. Tokens are
+      RS256, signed with their own keypair, so the set can be revoked on its
+      own — and an additional issuer is one branch in `deps.decode_token`,
+      which is the seam remote access needs later
+- [ ] LLM interface for natural-language flow authoring beyond the MCP tools
 
 ## Phase 2 — Backend: processing