The doors nobody means to open: a 404 a person can read, a 405 with `Allow`, an answered `OPTIONS` #45

A person who mistypes a path on production gets nine bytes of text/plain, and POST / and OPTIONS / get that same 404 where the status should say the method is wrong — the app's manners at the doors nobody means to open.

Checked against production rather than read: GET /nope → 404 not found as plain text with the full floor; GET /mcp → 405 with no Allow header; POST / → 404; OPTIONS / → 404.

Done looks like

• [ ] A request whose Accept prefers HTML gets a small server-rendered not-found page in the app's

own layout with a link back to /; everything else keeps text/plain. One function next to html() in src/http.ts, no new page module until there is a second real page.

• [ ] A known path with an unknown method answers 405 with an Allow header listing that path's

methods (GET, HEAD for /), not 404. src/routes.ts grows a way to list the methods for a path so the table is not spelled twice.

• [ ] OPTIONS on a known path answers 204 with the same Allow and no body; an unknown path

stays a 404.

• [ ] Every one of these carries the floor from src/http.ts unchanged, HEAD still answers like

GET with no body, and no error response invents a cache header.

• [ ] Tests in src/server.test.ts, each failing against today's server: HTML 404 for a browser,

plain 404 for a script, 405 with Allow for POST /, 204 with Allow for OPTIONS /, and the floor asserted on each.

Files src/http.ts, src/routes.ts, src/server.ts, src/page.ts, src/server.test.ts.

Risks Content negotiation that guesses: match text/html in Accept and default to plain text — never sniff a user agent. The 405 must come from the route table itself; a second list of methods per path is the bug this issue would otherwise introduce. #37 adds one row to src/routes.ts, so expect a one-line rebase, nothing more.

Ready now.

Fits Quill's brief: the page's manners, server-rendered, no JavaScript.