Harden CORS allowlist handling and cache behavior

Context

Luis' latest review on #184 approved the secure CORS default, but left several non-blocking hardening notes that should not be lost after the production-readiness batch merges.

The shipped behavior is correct for the main rollout, but there are edge cases worth tightening in a follow-up.

Follow-up work

• Treat a bare * anywhere inside a comma-separated CORS_ORIGIN allowlist as the deliberate wide-open case. Today CORS_ORIGIN="https://app.example.com,*" silently opens CORS to every origin while the warning says the * entry is unlikely to match.
• Add a negative allowlist test proving entries are exact matches, not prefix or substring matches.
• Document or mitigate the Vary: Origin cache behavior for multi-origin allowlists, especially the non-matching case that emits Access-Control-Allow-Origin: null.
• Keep the interaction with #185 explicit: when cors: false, Yoga's CORS preflight short-circuit is absent, so #185's local OPTIONS exemption is load-bearing.
• If browser clients ever send x-request-id, update allowedHeaders from content-type to include it, otherwise preflight will reject those requests.

Acceptance criteria

• CORS_ORIGIN parsing handles * consistently whether it is the whole value or one entry in a list.
• Unit coverage proves a malicious origin such as https://evil-example.com does not match https://example.com.
• Deployment docs mention the required Origin cache behavior for CDN/LB layers when using multi-origin allowlists.
• The rate-limit preflight dependency is documented in code or tests so the local OPTIONS exemption is not later removed as redundant.

Related

• #184
• #185

Start by tracing CORS_ORIGIN parsing and preflight handling, then review the rate-limit OPTIONS exemption and deployment documentation. Add coverage for wildcard and exact-origin behavior, document the required Origin cache handling and the #185 dependency, and verify all acceptance criteria.