Add reminders and location reminders CRUD support

[scottlovegrove]

Summary

• Add Reminder and LocationReminder models with appropriate field aliases (item_id → task_id)
• Add full CRUD methods for both regular reminders (/reminders) and location reminders (/location_reminders) in sync and async APIs
• Regular reminders support relative (via minute_offset) and absolute (via due) types
• Location reminders support geofenced triggers (on_enter/on_leave) with configurable radius

Test plan

• All 10 new tests pass (5 per reminder type: get, get_all, add, update, delete)
• All 88 tests pass (78 existing + 10 new)
• ruff format clean
• No new lint errors (3 pre-existing in models.py)

🤖 Generated with Claude Code

[doistbot-app]

This PR introduces valuable CRUD support for both regular and location reminders across the sync and async APIs. The implementation is solid, and the comprehensive test coverage is much appreciated. There are a few areas for refinement, specifically around adding the missing is_urgent field to the Reminder model, flattening input parameters rather than reusing the read-only Due response model, and ensuring test fixtures use distinct values to properly verify the item_id to task_id aliasing.

_{Share Feedback • Review Logs}

[lukemerrett]

@doistbot Please re-review this PR

[lukemerrett]

LGTM, have asked DoistBot to re-review it

[doistbot-app]

Hi @scottlovegrove, thanks for putting this PR together to support reminders and location reminders! The overall structure and tests look solid, but I noticed a couple of potential payload issues in api.py and api_async.py that we should verify against the API behavior.

First, in add_reminder, the request payload is built using kwargs_without_none(..., reminder_type=reminder_type, ...). Since the Reminder response model maps this property as type, it's highly likely the Todoist REST API expects the key "type" in the create request rather than "reminder_type". You can easily fix this by passing type=reminder_type to kwargs_without_none, since type is perfectly valid as a Python keyword argument.

Second, update_reminder currently doesn't accept a reminder_type parameter. If the API requires the type property when a user updates a reminder to switch it from relative to absolute (or vice versa), users won't be able to do so with the current signature. Additionally, since add_reminder defaults to "relative", users might accidentally misconfigure their request if they pass a due_date but forget to explicitly set reminder_type="absolute". It might be worth inferring the type dynamically based on the presence of due_* fields, or simply removing the default to require explicit intent.

Let me know what you think!