fix(tz): interpret calendar and briefing dates in user's local timezone

Two related bugs where the server defaulted naive datetimes to UTC instead
of the configured user timezone, causing all-day events to land on the
previous day and briefings to "disappear" at UTC midnight.

- New services/tz.py helpers: get_user_tz, user_today, user_briefing_date
  (the briefing day flips at 4am local to align with the compilation slot,
  so the 00:00-04:00 local window still shows yesterday's briefing until
  the new one is generated).
- calendar create/list/update tools now parse naive datetimes in the
  user's TZ before converting to UTC for storage, and tool descriptions
  tell the model to pass plain local dates.
- briefing_conversations.get_or_create_today_conversation and the
  reset-today route use user_briefing_date so the in-progress briefing
  doesn't get replaced at 19:00 NY / UTC midnight.
- _run_profile_closeout targets user-local "yesterday" for consistency.

Regression tests added for the TZ helpers and the calendar tool.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

src/fabledassistant/routes/briefing.py

@@ -330,10 +330,13 @@ async def reset_today_briefing():
     driven from the MCP when iterating on prompts. Pair with
     ``POST /api/briefing/trigger`` to immediately regenerate.
     """
-    from datetime import date as _date
     from sqlalchemy import delete as _delete
 
-    today = _date.today()
+    from fabledassistant.services.tz import user_briefing_date
+
+    # User-local briefing day (flips at 4am local), not ``date.today()`` —
+    # see services/tz.py for rationale.
+    today = await user_briefing_date(g.user.id)
     async with async_session() as session:
         result = await session.execute(
             select(Conversation).where(