Add CSRF protection to cookie-authenticated UI mutations and login

Problem

The UI mounts login/signup/logout plus a large set of authenticated state-changing POST/DELETE routes (internal/server/ui_routes.go:8-49 and subsequent project/issue routes). The authenticated UI group applies only uiAuthMiddleware; there is no CSRF token, Origin/Referer validation, or Fetch Metadata check.

The session cookie uses SameSite=Lax (internal/server/ui_auth_pages.go:121-129). That is useful defense-in-depth, but it does not prevent login CSRF because the attacker does not need an existing victim cookie, and it does not protect against same-site sibling-origin attacks.

Impact

An attacker can force a victim into an attacker-controlled account via login CSRF, creating a risk that the victim enters sensitive project data into the wrong account. If any sibling origin under the deployment's registrable domain is untrusted or compromised, it can also target cookie-authenticated issue, project, member, token, password, and passkey actions.

Acceptance criteria

• Add a CSRF defense for every cookie-authenticated unsafe method, including HTMX, multipart uploads, logout, and settings actions.
• Protect password login/signup against login CSRF; bind any login CSRF token/state before replacing the browser session.
• Prefer a well-reviewed synchronizer-token or signed double-submit implementation, with same-origin Origin/Referer or Fetch Metadata checks as defense-in-depth.
• Keep bearer-token API/MCP clients outside browser CSRF token requirements.
• Add negative tests for missing/invalid tokens and cross-origin requests, plus positive tests for standard forms, HTMX, and uploads.
• Document the expected sibling-subdomain trust model.