[Bug] `--cors 0` still emits `Access-Control-Allow-Origin: *` on GET responses (e.g. /v1/models)

Summary

With --cors 0, the server still stamps Access-Control-Allow-Origin: * on simple GET responses (e.g. /v1/models), so cross-origin browser JavaScript can still read them. The flag is honored on the preflight path — OPTIONS returns 404 with no consent headers, so preflighted requests (JSON-bodied POST /v1/chat/completions) are correctly blocked by browsers — but the unconditional wildcard header on simple responses leaks read access that --cors 0 is documented to close.

Practical impact: any web page a user visits can enumerate the local model roster via fetch('http://127.0.0.1:52625/v1/models') even when CORS is explicitly disabled — a fingerprinting vector ("this visitor runs a local LLM, here are the models") that the security tip in your docs (disable CORS when exposed) suggests should be closed.

Environment

• FLM v0.9.45, Windows 11, Ryzen AI 5 340 (XDNA2), NPU driver 32.0.203.314
• Server started as: flm serve llama3.2:3b --quiet --pmode performance --cors 0
• Command line confirmed on the running process via Win32_Process

Repro

1. flm serve llama3.2:3b --cors 0
2. Simple GET with a foreign origin:

   (Invoke-WebRequest 'http://127.0.0.1:52625/v1/models' -Headers @{Origin='https://evil.example'}).Headers['Access-Control-Allow-Origin']
   

   Observed: * — cross-origin JS can read the response.
   Expected with --cors 0: no Access-Control-Allow-Origin header at all.
3. Preflight (for contrast — this part behaves):

   Invoke-WebRequest 'http://127.0.0.1:52625/v1/chat/completions' -Method Options -Headers @{Origin='https://evil.example'; 'Access-Control-Request-Method'='POST'; 'Access-Control-Request-Headers'='content-type'}
   

   Observed: 404, no CORS headers → browsers refuse to send the preflighted POST. ✔️

Expected behavior

--cors 0 should suppress Access-Control-Allow-Origin on all responses, not only decline the preflight. (Non-browser clients are unaffected either way, so the fix shouldn't break native/API consumers.)

Found while adopting --cors 0 as our default per the security tip in your server docs — thanks for shipping the flag and the tip; this is just the last gap between them. Happy to test a build.

Start by locating the server's CORS handling for simple GET responses and compare it with the existing OPTIONS behavior described in the issue. Reproduce the PowerShell request to /v1/models with --cors 0 and verify that no Access-Control-Allow-Origin header is returned, while non-disabled CORS behavior remains unchanged.