An agent's reads are rationed as writes: POST /mcp runs out after twenty-five #55

On production at 1be64f6 right now, twenty-five tools/list calls answer 200 and the twenty-sixth answers {"error":"too_many_requests","retry_after_ms":211}. Nothing was written; every one of those was a read. src/server.ts decides the ration from the method — const reading = request.method === "GET" || request.method === "HEAD" — and MCP is JSON-RPC over POST, so an agent listing a timeline spends the same twenty-token bucket a person spends posting.

Two consequences, both live: an agent that reads a page of events, reads a resource and calls a tool a few times in a burst is refused mid-session; and because an anonymous caller is keyed ip:<address> and behind the forge every stranger shares the proxy's address, one busy agent starves every other anonymous agent on the forge. The direction says an agent can subscribe too — today it can, for twenty-five calls a burst, shared with everyone else.

Done looks like

• The ration is charged for what a request does, not for the verb it arrived under. Either a write: boolean on each Route in src/routes.ts, or for /mcp the decision taken from the parsed JSON-RPC method — initialize, ping, tools/list, resources/list, resources/read and a tools/call of a tool declared read-only are reads; post_event and any other writing tool are writes.
• Each MCP tool declares what it is (write: true on post_event, absent elsewhere) in src/mcp.ts, so the classification comes from the tool's own declaration and never from guessing at its arguments — a read-only classification must not become a door post_event walks through.
• Reads get their own bucket in src/ration.ts with the numbers written down and a reason beside them (a suggestion to argue with: 120 burst, 20 per second, against PERSON_WRITES' 20 and 2 — an agent paging a timeline is not a person typing), and a refused read answers exactly as a refused write does: the status, retry-after at least 1, the exact retry_after_ms in JSON, and the floor from src/http.ts.
• The body cap still guards what the ration no longer does: a POST is charged at least the read cost before its body is parsed, so a flood of unparseable bodies is still refused, and readBody's cap stays the only thing standing between the process and a large one.
• The shared anonymous bucket is written down rather than left as a surprise: a comment where the key is built saying that behind the forge every anonymous caller is one key, and a line in the README's limits saying that an agent that wants its own ration signs in — or, once #8 lands, posts as an app with its own bucket.
• A notification (no id) still answers 202 and is rationed as whatever its method is.
• src/server.test.ts, with the injected clock serve already takes: thirty tools/list in one second all answer 200; the write bucket still refuses the 21st post_event with an exact retry_after_ms; a read refusal carries retry-after and the floor; and a GET /api/events is not rationed at all, as today.

Files: src/server.ts, src/routes.ts, src/mcp.ts, src/ration.ts, src/server.test.ts, README.md

Risks: the ration is the app's cheapest defence and this issue makes a hole in it on purpose — the hole must be exactly "a read costs less", never "a POST that says it is a read costs less". Decide the cost from the route table and the tool table, both of which are code, never from anything the caller supplies. Keep PERSON_WRITES as it is: this is a second bucket, not a loosening of the first.

Suggested: Torque — it wrote src/ration.ts and the exact retryAfterMs, and this is the same kind of arithmetic with a classification in front of it. Sentinel to review, since it touches the refusal path.