Catchlist_todo

The right pattern here is to convert all timestamps from the DB's UTC datetime object into a localized timestamp through the db model's as_dict function.

so convert this:
"start_time": "2026-04-02T09:00:00+00:00"

into this
"start_time": "09:00"

or this, where appropriate:
"start_time": "2026-04-02T09:00"

Doing this will break all timestamp-related tests and should be done in conjunction with creation of a bunch of new timezone/timestamp-focused tests for all entities.

I've decided against implementing timezone conversion logic in the as_dict functions; the logic is complex enough that it deserves its own home.

I'm going to implement a layer between the service and API layers, there will be one module per entity (in the database folder for that entity).

I ended up just storing timezones for calendars,routines, and sessions.

Additionally there's a presentation layer in the database that can be used to translate timestamps between timezones, but hopefully it won't get much use as we're storing timezone info in the calendar/routine/session.

we're no longer "JUST DO EVERYTHING IN UTC" but that would have been a mess for recurring events that are less than 6 hours away from the date boundary.

Anyway, timestamps come through the API and frontend cleanly now.

commitments, checkins, and timeframes will still be encoded in UTC.

Still probably need to do some testing around these