Add CORS preflight FIX

[Mitch5000]

================================================================================
PULL REQUEST

Title:
Add CORS preflight (OPTIONS) tests verifying the corsOrigins allowlist

Base: main
Branch: add-cors-preflight-tests
Type: test-only (no production code changes)
Closes: the CORS preflight test-coverage issue

---

PROBLEM

app.ts mounts the cors middleware with config.corsOrigins (or unrestricted, if
unset):

app.use(cors(config.corsOrigins ? { origin: config.corsOrigins } : undefined));

However, no test exercised 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.

Verified before this change:

• src/config.test.ts covers only CORS_ORIGIN env parsing (loadConfig), not
  HTTP-layer behavior.
• src/corsAllowlist.test.ts covers only simple requests (GET /health with an
  Origin header) - never an OPTIONS preflight.
• A grep across all src/**/*.test.ts suites confirmed zero OPTIONS requests.

A misconfigured or silently-ignored CORS setting is a real cross-origin
exposure risk, and before this change it would not have failed any test.

---

WHAT CHANGED

Test-only change: one new file, src/cors.test.ts, containing three tests.
Each test boots createApp() under a specific CORS_ORIGIN configuration and
issues a supertest OPTIONS request to /api/v1/anchors - the preflight a
browser would send before the mutating route POST /api/v1/anchors - with an
Access-Control-Request-Method: POST header:

1. Allowlisted origin is reflected
   CORS_ORIGIN=https://allowed.example, request Origin matches it.
   Asserts: status 204 and
   Access-Control-Allow-Origin: https://allowed.example (reflected, not a
   wildcard), plus Access-Control-Allow-Methods permitting POST.

2. Disallowed origin is not reflected
   CORS_ORIGIN=https://allowed.example, request Origin=https://evil.example.
   Asserts: status 204 and the Access-Control-Allow-Origin header is ABSENT
   (and explicitly not the disallowed origin).

3. Unrestricted default still holds when CORS_ORIGIN is unset
   Asserts: status 204 and Access-Control-Allow-Origin: *,
   matching the behavior documented in config.ts and README.md
   ("If unset, every origin is permitted").

Conventions followed:

• Env handling mirrors the existing src/corsAllowlist.test.ts pattern:
  process.env.CORS_ORIGIN is captured up front and restored in afterEach,
  so the suite is hermetic regardless of the ambient environment.
• /api/v1/anchors was chosen as the target path because POST /api/v1/anchors
  is the canonical mutating route already used throughout the app-level
  suites (maintenanceMode.test.ts, bodyLimit.test.ts, etc.).
• Assertions were verified against the installed cors@2.8.6 source: the
  middleware terminates any OPTIONS request itself (preflightContinue
  defaults to false, optionsSuccessStatus 204), an array allowlist uses
  exact-string matching and reflects a matching request origin, a
  non-matching origin gets no Access-Control-Allow-Origin header, and the
  default origin '*' is emitted only when no allowlist is configured.

---

VALIDATION

Full CI pipeline (lint -> build -> test) green, run locally on Node 20 to
match CI:

LINT   exit 0
BUILD  exit 0   (tsc; no conflicts, dist/cors.test.js emitted)
TEST   41 suites, 472 tests passed   (baseline was 40 suites / 469 tests)
COV    97.16% statements, 97.59% lines, 95.73% functions overall
       (bar: 95%); app.ts and config.ts remain at 100%

Mutation check (simulated and reverted; not part of this diff):

#  Simulated misconfiguration                     Result
-  ---------------------------------------------   -------------------------
1  Allowlist mount replaced with                   Tests 1 and 2 FAIL
   unrestricted cors() in app.ts                   (wildcard reflected;
                                                   header present for the
                                                   disallowed origin)

This is exactly the silently-ignored-allowlist risk described in the issue,
so the new tests demonstrably guard against it. app.ts was restored after the
check; git diff confirms it is byte-identical to HEAD, and git status shows
the only change in this PR is the new test file.

---

REVIEWER NOTE

No production code was changed, so this PR cannot alter runtime behavior on
its own; it only locks the current behavior in. If the cors mount in app.ts
ever evolves (e.g. credentials support, dynamic origin callbacks), extend
these preflight tests alongside it so the allowlist stays verified at the
HTTP layer rather than only in config.ts's parsing logic.

---

FILES CHANGED

File              Change
---------------   ----------------------------------------------------------
src/cors.test.ts  Created - three OPTIONS preflight tests against the
                  mutating route POST /api/v1/anchors (allowed origin
                  reflected, disallowed origin not reflected, unrestricted
                  default when CORS_ORIGIN is unset)

Total: 1 file created, 0 files modified.

Closes #151