fix(security): harden CSP policy and hide nginx server tokens

[myml]

What

Harden Content Security Policy (CSP) and hide nginx server version information.

Why

CSP Hardening:

• 'unsafe-inline' and 'unsafe-eval' in script-src allow inline scripts and eval(), which can enable XSS attacks
• ws: wss: http://localhost:* https://localhost:* in connect-src allows WebSocket and localhost connections that may not be needed in production

Nginx Server Tokens:

• By default, nginx exposes its version in HTTP response headers (Server: nginx/x.x.x)
• This information can help attackers identify known vulnerabilities

How

1. Remove 'unsafe-inline' 'unsafe-eval' from script-src directive
2. Restrict connect-src to 'self' only
3. Add server_tokens off; to nginx configuration

Testing

• Verify the application still works correctly with the stricter CSP
• Check nginx response headers do not contain version information

Impact

• May break functionality that relies on inline scripts or eval() - needs testing
• WebSocket connections from frontend will be blocked - verify if this is intentional
• Nginx version will no longer be exposed in Server header

[FenjuFu]

The direction is right (dropping 'unsafe-inline'/'unsafe-eval' from script-src and tightening connect-src are real XSS-surface reductions, and server_tokens off is a clean win). The risk is that these three are the classic ways a strict CSP breaks a running SPA, so this needs a smoke test against the production build (not dev) before merge:

• 'unsafe-eval' removal: breaks any dependency that uses eval/new Function (some date/i18n/wasm/templating libs do). Worth a grep of the bundle.
• 'unsafe-inline' removal from script-src: breaks if index.html or any lib injects an inline <script> or inline event handlers. Vite's module output is external, so usually fine — but verify.
• connect-src 'self': drops ws:/wss: and localhost:*. Same-origin SSE/fetch stay allowed, but if notifications still use a WebSocket or any cross-origin endpoint (and [Feature] Replace notification SSE with proxy-friendly HTTP polling #622 is still tracking the SSE→polling move), they'll be blocked. Confirm every XHR/fetch/SSE target is same-origin.

If you've already run the built frontend through login + notifications + skill browse with the console open and it's clean, say so in the PR and this is good to go.

[myml]

We've run through login, notifications, and skill browsing on the built frontend with the console open – no CSP errors and all features work as expected. This has been running stably in our internal production for several days, so it should be good to merge. @FenjuFu

[FenjuFu]

Re-reviewed after the production-build smoke evidence. The diff is limited to removing script unsafe-inline and unsafe-eval, restricting connect-src to same-origin, and disabling nginx server tokens. Login, notifications, and skill browsing were exercised without CSP violations, and all remote checks, DCO, and CLA are green.