Report calendar conflicts after creating or editing an event

[tabmail-kmyi]

Problem

TabMail can create or edit a calendar event successfully without telling the agent that the resulting time overlaps another event. The write is valid, but the user may leave the conversation unaware of a conflict that the local calendar can already expose.

Desired behavior

After a successful calendar_event_create or calendar_event_edit, use the existing calendar read/search bridge to check the final event window for overlaps and include any confirmed conflicts in the tool completion returned to the agent.

Boundaries

• Do not block, undo, or silently change the event the user requested.
• Exclude the edited event itself and use the final stored start/end values.
• A conflict-check failure must not turn a successful write into a reported write failure; report that conflict status could not be checked.
• Reuse the existing calendar query and event-normalization primitives. Do not add a second calendar index or a parallel overlap engine.
• Cover create, edit, all-day events, recurring-event scope, and no-conflict behavior with focused tests.

[tabmail-kmyi]

Re-triaged under the new P0–P5 priority scheme (2026-09-04): P3 → P4 — feature (conflict reporting after a write).