Allow header accuracy: advertise OPTIONS, and 405 instead of 404 on single-verb routes

[thehabes]

Follow-up to #296, which was resolved by #295. Two small Allow accuracy gaps remain. Both sit outside the scope of #296, which covered only routes that already return a 405.

OPTIONS is never listed in Allow

rest.sendMethodNotAllowed() emits only the verbs registered on the route, so no 405 response advertises OPTIONS. The cors middleware in app.js answers OPTIONS at every path with a 204, even with no Origin header present:

OPTIONS /v1/api/create  ->  HTTP/1.1 204 No Content
OPTIONS /v1/api/query   ->  HTTP/1.1 204 No Content
OPTIONS /v1/id/:_id     ->  HTTP/1.1 204 No Content

RFC 9110 §10.2.1 defines Allow as the set of methods supported by the target resource, so OPTIONS belongs in every value we emit.

Suggested approach: append OPTIONS inside rest.sendMethodNotAllowed() and rest.createPatchOverrideMiddleware() rather than editing all 20 call sites, then update getAllowedMethods() in routes/__tests__/route_wrappers.test.js so the derived expectation still matches.

Single-verb routes 404 where a 405 fits better

These routes register one verb with no .all() fallback, so a wrong method falls through to the app's 404 handler with no Allow header at all.

Request	Current	Expected
POST /v1/api	404	405 with Allow: GET,HEAD,OPTIONS
GET /v1/api/accessToken	404	405 with Allow: POST,OPTIONS
GET /v1/api/refreshToken	404	405 with Allow: POST,OPTIONS
POST /v1/	404	405 with Allow: GET,HEAD,OPTIONS

Sources: router.get('/api', ...) in routes/api-routes.js, /accessToken and /refreshToken in routes/compatability.js, and router.get('/', ...) in routes/static.js.

Worth deciding whether /v1/ is wanted here. That router also serves the static public directory, so an .all() fallback has to sit after the static middleware or it will shadow real files.