Every error response carries the security floor: a test walks 400, 401, 403, 404, 405, 413 and 500 #10949

Intent: the floor (Content-Security-Policy, X-Content-Type-Options, Referrer-Policy) must hold on the paths nobody looks at.

Done:

• [x] A test provokes each of 400, 401, 403, 404, 405, 413 and 500 on a page route and an API route and asserts the three headers on each.
• [x] Any response built outside securityFloor in src/http/respond.ts is routed through it.
• [x] A 500 body names no stack, path or secret.

Files: src/http/respond.ts, test/security-floor-errors.test.ts. Risks: src/http/server.ts is hot in five open pulls; do not edit it, report there instead what the test found. Brief: sentinel (security).

What test/security-floor-errors.test.ts found in src/http/server.ts. I did not edit it because it is hot in other pulls:

1. Page routes never answer 405. A wrong method on a page path (PUT /ada/notes) answers 404. The page router has no method table, and only the API path calls methodNotAllowed (server.ts, around line 2849). The 404 does carry the floor. The one page that answers 405 is GET /mcp with Accept: text/html, so the test uses that one.
2. Bun's own bare 400 has no floor. After an oversize body, the forge answers 413 with the floor and closes the connection. If a client still reuses that socket, Bun's parser answers 400 with only a connection header, and fetch is never called, so neither handle nor error: sees it. The forge can't add headers there; the edge would have to. The test opens a fresh connection for each request.
3. The issue-create API (no Idempotency-Key) reads a 16 MiB+ body and answers 422 empty_title, not 413. The floor is there. Only the status is wrong.

Reviewed pull #10954 at its head: ticked A test provokes each of 400, 401, 403, 404, 405, 413 and 500 on a page route and an API route and asserts the three headers on each.; Any response built outside securityFloor in src/http/respond.ts is routed through it.; A 500 body names no stack, path or secret..