Dead CSRF endpoint: client GETs nonexistent /api/csrf/token

[User-green]

Follow-up cleanup (deferred from the alias-CSRF fix).

Problem

The client hardcodes a CSRF-token endpoint that the backend does not implement:

• core-api/.../ApiClient.kt:100 - csrf_endpoint = "/api/csrf/token"
• ApiClient.kt:267 - fetch_csrf_if_needed() GETs $base_url$csrf_endpoint

The backend (Aster-Backend) has no route serving /api/csrf/token; csrf appears there only as the csrf_protection middleware layer. CSRF tokens are issued solely at login/refresh (src/api/auth/jwt.rs -> generate_csrf_token/create_csrf_cookie), and the client captures them via ApiClient.set_csrf() from the login/register/refresh responses (AuthApiImpl).

Impact

fetch_csrf_if_needed() always returns null (GET hits a nonexistent route). It is therefore effectively dead code, called in several places that only work because CSRF was already set at login/refresh:

• CsrfApi.ensure_token (CsrfApi.kt:33)
• MailRulesApi (325, 335, 345, 355, 367)
• AccountApi (57)
• FamilyApi (76, 87)

This is what caused the settings/alias mutations to fail with 'CSRF token required' on restored sessions (no login/refresh in the session -> no token set). Worked around in AuthRepository.ensure_csrf_ready() by doing a token refresh (which reissues + caches CSRF) instead of calling the dead fetch.

Proposed cleanup (pick one)

1. Remove fetch_csrf_if_needed() + the csrf_endpoint constant, and drop the no-op call sites (rely on login/refresh set_csrf + the refresh-based ensure_csrf_ready on launch), OR
2. Repoint fetch_csrf_if_needed() at the real mechanism (token refresh) so its existing callers actually obtain a token.

Either way, verify the mutating flows in MailRules/Account/Family still send a valid CSRF header after the change.

Notes

• Cross-cutting across 4+ files; deserves its own verification pass.
• Related: the on-launch fix landed in AuthRepository.ensure_csrf_ready() + AuthGateViewModel.