Lock down shipped auth CORS + CSP defaults (opt-in for permissive)

[chefsale]

Context

The shipped auth config (crates/auth/config/config.toml, baked into the image via Dockerfile.auth) ships permissive web-security defaults:

• [cors] allow_all_origins = true → CorsLayer::permissive() (see crates/auth/src/api/routes.rs).
• [security.headers.csp] script_src = ["'self'", "'unsafe-inline'", "'unsafe-eval'"] and style_src = [... 'unsafe-inline'].

This was intentionally not changed in the hardening pass (#3104): flipping allow_all_origins=false (with no known allowed origins) or dropping the CSP unsafe-* directives blindly would break the embedded auth UI and browser deployments. The correct values depend on how the service is deployed, so it needs a product/deployment decision rather than a blind default.

Decisions needed

1. CORS — what should the default be? Options: keep permissive but document it as dev-only; ship allow_all_origins=false with a configurable allowed_origins (empty default, operators must set it); or an env-driven allowlist.
2. CSP — does the embedded auth frontend actually require unsafe-inline / unsafe-eval (e.g. inline styles, wasm)? If it can be built with nonces/hashes, tighten script_src/style_src to drop the unsafe-* directives.

Definition of done

• Locked-down CORS/CSP defaults in the shipped config, with permissive behavior available as explicit opt-in.
• Auth UI verified working under the new defaults (login flow, assets, wasm if any).

References

• Hardening PR that flagged this: ci: supply-chain & image hardening (action pins, image digests, checksums, secret handling) #3104