fix(server): cap every request body to prevent a JSON/MCP OOM

[benvinegar]

What & why

The previous PR (#117) bounded POST /api/assets, but that was only the binary half of the same vector. Every other write endpoint — /api/surfaces, /api/snippets, /api/comments, /api/sessions, /api/sessions/:id/trace, /api/theme — and /mcp still read their body with an unbounded c.req.json(). So the same unauthenticated out-of-memory flood was still reachable — an attacker just POSTs a multi-gigabyte JSON body to /api/surfaces (or /mcp). The local default ships with no auth token, so on any board reachable beyond localhost these endpoints are open. (On Cloudflare Workers the platform caps request bodies ~100 MB by plan; the Node self-hosted path has no such backstop — so this matters most there.)

Fix

Use Hono's built-in bodyLimit everywhere, in two scopes:

// global cap on every JSON/MCP body
const limitBody = bodyLimit({ maxSize: MAX_BODY_BYTES, onError: (c) => c.json({ error: "request body too large" }, 413) });
app.use("*", (c, next) => (c.req.path === "/api/assets" ? next() : limitBody(c, next)));

// the asset route's own, tighter cap (keeps the asset limit + wording)
const limitAssetBody = bodyLimit({ maxSize: MAX_ASSET_BYTES, onError: (c) => c.json({ error: `asset exceeds ${MAX_ASSET_BYTES} bytes` }, 413) });
app.post("/api/assets", limitAssetBody, async (c) => { const buf = new Uint8Array(await c.req.arrayBuffer()); /* ... */ });

• MAX_BODY_BYTES = 16 MiB global — clears the largest legitimate body (a base64-encoded asset over MCP, ~4/3 of the 5 MiB asset cap) while bounding a flood.
• Streaming-safe: bodyLimit short-circuits on an oversize Content-Length and otherwise aborts the stream at the cap, so a chunked body (no Content-Length) can't slip past — the gap fix(server): cap the asset-upload body while streaming to prevent an OOM #117 closed for assets.
• After auth: an unauthenticated request on a token board is refused (401) before its body is read; on a no-token board the cap still bounds it.
• /api/assets is exempt from the global cap and instead carries its own bodyLimit at the (stricter) asset limit, so the tighter bound is the only one that applies.

Also folds in the asset route onto the primitive

This PR additionally replaces #117's hand-rolled readBodyCapped (a custom streaming reader + manual Content-Length check) with the scoped bodyLimit above — same behavior and limit, one framework primitive instead of a bespoke reader (net −37 lines). Done here rather than as a follow-up so we don't merge the custom reader only to delete it.

Tests

test/api.test.ts adds the global body cap rejects oversize JSON and MCP bodies (over-cap Content-Length → 413 on a REST write endpoint and /mcp). The asset route's existing tests from #117 — oversize Content-Length, chunked-stream cap (asserts the read stops early), and multi-chunk reassembly — all still pass against the scoped bodyLimit, confirming the swap preserved behavior. The streaming-abort path itself is Hono's bodyLimit (tested upstream).

• npm run typecheck, npm run lint, npm run format:check, npm test (205/205) ✅

🤖 Generated with Claude Code