fix: handle OPTIONS preflight requests

[SsuJojo]

Summary

• Add a global OPTIONS handler for browser/client preflight requests
• Return CORS preflight headers before normal route middleware, covering GET endpoints like /v1/models

Test plan

• Not run per request

[icebear0828]

Review notes:

这个改动整体低风险，我没有看到 blocker。两个小建议可以考虑顺手补：

1. Vary 建议包含 Access-Control-Request-Method；preflight 响应也会受 request method 影响。
2. 当前 app.options("*") 放在 requestId/logger 等全局 middleware 前，所以 preflight 不会进入统一 request id / logging。如果项目希望所有请求都有日志，可以调整顺序；如果是刻意让 preflight 更轻量，也可以保持现状。

这两个都不是阻塞问题。

[icebear0828]

感谢 PR！review 完发现两处需要先处理：

[P1] CORS preflight 反射任意 Origin — src/index.ts:107-112
当前实现把任何 Origin + Access-Control-Request-Headers 都反射回去，意味着任意网页（哪怕是恶意站点）都能拿到 preflight 通过然后向 localhost 的 dashboard / admin / API 端点发 JSON / PUT / DELETE。即便浏览器后续会 block CORS 响应读取，副作用（如 /api/proxies 修改、/auth/accounts/health-check）已经发生。
建议：把允许的 origin 限制成已知 dashboard URL 白名单，不要覆盖 admin 路由。

[P2] 实际响应缺 CORS header — same file
当前只回 OPTIONS preflight，但真正的 GET/POST 响应没设 Access-Control-Allow-Origin，合法的跨域 browser client 在 preflight 后仍会被浏览器丢响应。如果目的是 CORS 支持，需要在非-OPTIONS 路径也用同一份 origin policy 加 header。