CORS responses differ from the Python proxy

## Current behaviour

The router uses a hardcoded `CorsLayer::permissive()` (`src/routes/mod.rs`), which differs from the Python proxy in two ways:

1. **Not configurable.** The Python proxy exposes `allow_origins` in settings and runs with `allow_credentials=True`; the Rust proxy always answers `access-control-allow-origin: *` with no credentials support, and there is no setting to narrow origins.

2. **Duplicate `Vary` header lines.** Each tower-http layer appends its own line, so every response carries:

```
vary: accept-encoding
vary: origin, access-control-request-method, access-control-request-headers
```

Starlette merges these into a single `Vary` line. The two forms are semantically identical per RFC 9110, but intermediaries that only read the first line mishandle it — and the CORS line is noise anyway while the origin is a wildcard (the response does not vary by origin).

Start in src/routes/mod.rs by reading the existing CorsLayer::permissive() setup and tracing how router settings are configured. Compare the Rust response behavior with the Python proxy details in the issue; done means configurable origins and credentials match the proxy, and the response no longer exposes the problematic duplicate or unnecessary Vary behavior.

Written by the indexing model from the issue text.