fix: harden clip server against CSRF and arbitrary file write (security)

[xkvrum1n]

Summary

This PR fixes two security vulnerabilities in the local clip server (src-tauri/src/clip_server.rs) identified during an internal security audit.

Vulnerabilities Fixed

1. CSRF via wildcard CORS — HIGH (CVSS 8.1)

Before: The server returned Access-Control-Allow-Origin: * on all responses, allowing any website to make cross-origin requests to the clip server running on 127.0.0.1:19827.

After: Replaced wildcard with an explicit allowlist. Requests from unlisted origins receive Access-Control-Allow-Origin: null.

const ALLOWED_ORIGINS: &[&str] = &["http://localhost:1420", "tauri://localhost"];

2. Arbitrary file write via unvalidated projectPath — CRITICAL (CVSS 9.1)

Before: The /clip POST endpoint accepted any filesystem path in the projectPath field with no validation, allowing a caller to write attacker-controlled content to any location on the user's filesystem.

After: The submitted path is validated against the list of registered projects. Unrecognized paths are rejected with an error.

if !is_registered {
    return r#"{"ok":false,"error":"projectPath is not a registered project"}"#.to_string();
}

Attack Chain Broken (Combined CVSS 9.3)

Without these fixes, a malicious website could:

1. Call GET http://127.0.0.1:19827/projects to enumerate all wiki project paths (unauthenticated endpoint)
2. Use CSRF (wildcard CORS) to POST to /clip with each discovered path and arbitrary content
3. Overwrite files across all of the user's wiki projects in a single page visit

Both prerequisites are now blocked.

Testing

1. Build and launch the app — verify clip/ingest functionality works normally
2. CORS fix: curl -H "Origin: http://evil.com" http://127.0.0.1:19827/projects → response header should be Access-Control-Allow-Origin: null
3. Path validation fix: POST to /clip with a projectPath not in the registered project list → should return {"ok":false,"error":"projectPath is not a registered project"}