Add CORS preflight (`OPTIONS`) test coverage for mutating routes in `app.ts`

[Jagadeeshftw]

📌 Description

app.ts mounts the cors middleware with config.corsOrigins (or unrestricted, if unset), but there's no apparent test exercising an actual OPTIONS preflight request against a mutating route (e.g. POST /api/v1/anchors) to confirm the configured corsOrigins allowlist is actually honored by the cors package's preflight response headers.

🧩 Requirements and context

• Add a test booting createApp() with CORS_ORIGIN set to a specific origin, issuing an OPTIONS preflight to a mutating route with a matching Origin header, and asserting Access-Control-Allow-Origin reflects it.
• Add a test with a non-matching Origin header asserting the header is absent/doesn't reflect the disallowed origin.
• Add a test with CORS_ORIGIN unset asserting the current unrestricted-origin behavior (documented in config.ts) still holds.

🛠️ Suggested execution

• Add tests to src/config.test.ts-adjacent app-level tests or a new cors.test.ts, constructing createApp() under each CORS_ORIGIN configuration and issuing supertest OPTIONS requests.

✅ Acceptance criteria

• New tests confirm allowed origins are reflected, disallowed origins are not, and the unrestricted default behaves as documented.

🔒 Security notes

Verifies the CORS allowlist configuration actually takes effect at the HTTP layer, not just in config.ts's parsing logic — a misconfigured or silently-ignored CORS setting is a real cross-origin exposure risk.

📋 Guidelines

• Minimum 95% test coverage
• Clear documentation
• Timeframe: 96 hours

[XxHugheadxX]

Reviewed the code before applying — the gap is real, though narrower than the
suggested execution implies. A few things I confirmed that shape my approach:
src/corsAllowlist.test.ts already covers all three acceptance scenarios —
allowed origin reflected, disallowed omitted, unset CORS_ORIGIN falling back to

• — but only for simple requests, never an OPTIONS preflight, so I'll extend
  that file rather than add a parallel cors.test.ts that duplicates it. Mounting
  order matters here: cors sits at app.ts:41, ahead of apiKeyAuth, rateLimiter and
  idempotency, and cors@2.8.6 defaults to preflightContinue: false, answering a
  preflight with 204 via res.end() without calling next() — so OPTIONS never
  reaches the auth layer and the allowlist is the sole gate on that path. The
  subtle part is that a disallowed preflight isn't an error: cors still returns
  204, just without Access-Control-Allow-Origin, because enforcement is the
  browser's. The assertion has to be on header absence, not on status. Tests:
  preflight against POST /api/v1/anchors under each config, asserting
  reflection/absence plus Access-Control-Allow-Methods to prove it's genuinely
  the preflight response.