feat(email): create calendar events from email context

[itomek]

Closes #1274

Before: create_event_from_email would POST {"dateTime": ""} straight to the calendar when an email had no parseable time — silently creating a bogus event. After: extract_event_details pulls title/attendees/time-signal from the email, and creation fails loudly (NoEventDateTimeError, creates nothing) when there's no usable date/time, so the agent asks for a time instead of fabricating one.

Test plan

• 17 unit tests (test_create_event_from_email.py): title/attendees/time extracted from a clear fixture email → event created with matching fields; no-datetime negative case (blank/missing/whitespace/partial) raises and creates nothing, at both impl and tool-boundary layers
• full email suite → 96 passed; lint clean

Stacked on #1273 (calendar lane 1272→1273→1274); base tmi/issue-1273-calendar-conflict, retargeted to integration as the chain merges. Deterministic extraction (no eval-trigger).

[github-actions]

Review: feat(email): create calendar events from email context (#1355)

Summary

Solid, well-tested fail-loud hardening of calendar event creation — this is exactly the behaviour CLAUDE.md's "No Silent Fallbacks" rule asks for, and the negative-case coverage is thorough. The one thing worth clarifying before this is "done" as described: the new extract_event_details function is fully tested but never called from any production path — the agent-facing create_event_from_email tool takes start_iso/end_iso straight from the LLM and never invokes the extractor. So the value this PR actually ships is the fail-loud guard (NoEventDateTimeError + _has_usable_time) and the window-ordering check, not the extractor the description leads with. Non-blocking, but a reviewer should know the runtime narrative differs from the description.

(Note: I reviewed statically — I couldn't run the suite locally, so I'm trusting the PR's "96 passed; lint clean" CI claim. No prompt-injection content in the diff.)

Issues Found

🟡 extract_event_details is unused in production (calendar_tools.py:675)
The function is defined and gets 7 dedicated tests, but grep finds zero callers outside the test file — the registered create_event_from_email tool never calls it. The PR description frames it as the core of the fix ("extract_event_details pulls title/attendees/time-signal from the email"), yet at runtime the LLM does that extraction and the function is dead code. Two clean resolutions: (a) if it's scaffolding for a later stacked PR, say so in a one-line comment so it doesn't read as wired-in; (b) if it's meant to be live now, call it from the tool to pre-fill/validate before the LLM-supplied args reach create_event_from_email_impl. As-is it risks quiet bit-rot — a tested function nobody invokes.

🟢 has_datetime can false-positive on casual mentions (calendar_tools.py:703)
_TIME_RE matches bare weekday/relative words, so "see you tomorrow" or "talk Monday" flags has_datetime=True with no real slot. Harmless today since has_datetime gates nothing (the impl guard keys off actual start/end), but if you ever wire the extractor in, this becomes a source of bogus "time found" signals. Worth a comment noting has_datetime is a coarse hint, not a commitment.

🟢 Duplicated datetime pull (calendar_tools.py:740, 751)
start.get("dateTime") or start.get("date") is computed in _has_usable_time and again for the ordering check. Trivial; only worth folding if you touch this block again.

Strengths

• Textbook fail-loud. NoEventDateTimeError(ValueError) is a clean choice — the tool's except Exception boundary turns it into a structured ok=False envelope, while callers that care can match the specific type. Exactly the boundary-translation pattern CLAUDE.md allows.
• Negative cases are the star. Blank / missing-key / whitespace / partial / inverted / zero-length / all-day are all covered at both the impl and tool-boundary layers — the part most PRs skip.
• Good reuse, no parallel parser. Leans on the existing _TIME_RE and read_tools.extract_sender_email rather than reinventing extraction, and the tests mirror the established test_calendar_conflicts.py conventions (sys.path bootstrap, _make_email_agent, _TOOL_REGISTRY access).

Verdict

Approve with suggestions. No blocking issues — the fail-loud guard is correct and well-tested. Before closing the loop on #1274, clarify the extract_event_details wiring question (🟡): either land its caller or mark it as future scaffolding so it doesn't drift into dead code.