fix(auth): resolve V2 API 429 rate limit during authentication

[mattpetters]

Summary

Fixes #33 - V2 API returns 429 rate limit during client.connect() after fresh OAuth flow.

Root Cause

TickTick added rate limiting at their AWS ELB level that blocks requests missing proper browser headers. The SDK's minimal header approach was being flagged as bot traffic.

Changes

• Add Origin: https://ticktick.com header (required)
• Add Referer: https://ticktick.com/ header (required)
• Update X-Device header to match web app format with full device info
• Update web app version from 6430 to 8010

Investigation

Headers were identified by:

1. Capturing a working auth request from ticktick.com via Chrome DevTools
2. Comparing against the SDK implementation
3. Testing minimal header sets via curl to identify the required ones

Testing

Verified fix works with:

• Direct Python SDK connection test
• MCP server startup

2026-02-05 14:18:48,257 - httpx - INFO - HTTP Request: POST https://api.ticktick.com/api/v2/user/signon?wc=true&remember=true "HTTP/1.1 200 "
2026-02-05 14:18:48,257 - ticktick_sdk.api.v2.auth - INFO - Successfully authenticated user: ...

[LittleNightmare]

Thanks for this fix — verified working here (Windows 11, ticktick-sdk 0.4.3 installed via pipx, used as an MCP server): sign-on went 429 → 200 with these headers.

One heads-up from testing: after applying only this patch, /api/v2/user/signon succeeds but regular V2 data requests still get 429. Concretely, GET /api/v2/batch/check/0 fails during the post-auth verification, and every read tool call (list_projects, etc.) returns "Rate limit exceeded". I reproduced this twice back-to-back — sign-on 200 and batch/check 429 within the same second — which points to header-based blocking on that endpoint as well, not genuine rate limiting.

The root cause is that request headers are built in two independent places, and this PR only covers the auth one:

• SessionHandler._get_headers() in api/v2/auth.py — ✅ patched by this PR
• TickTickV2Client._get_auth_headers() / _get_x_device_header() in api/v2/client.py — ❌ still sends Mozilla/5.0 (rv:145.0) Firefox/145.0, the minimal 3-field X-Device, and no Origin/Referer

Locally I extended the same treatment to the data path (Chrome User-Agent + Origin + Referer + full web-app X-Device format, reusing the SessionHandler helpers, plus aligning the UA constants). After that, batch/check returns 200 and all tools work.

Would you consider extending this PR to cover api/v2/client.py too? Happy to test any follow-up.