fix(mcp): validate actual_end is not before actual_start in fix_actual_times tool

[amir-rezaei]

Description

This PR resolves part of issue #1143 by adding validation to the MCP fix_actual_times tool in packages/taskdog-mcp/src/taskdog_mcp/tools/task_lifecycle.py to reject inputs where actual_end < actual_start.

Details

• Previously, MCP fix_actual_times validated only actual_duration > 0, permitting invalid timestamp configurations where actual_end was earlier than actual_start.
• This PR checks start_dt and end_dt to raise ValueError("actual_end cannot be before actual_start") if end_dt < start_dt.

[Kohei-Wada]

Thanks, but closing this one — the check it adds is already enforced, and in a stricter form, one layer down.

Task.fix_actual_times (packages/taskdog-core/src/taskdog_core/domain/entities/task.py:394) already raises TaskValidationError when actual_end < actual_start:

if new_start is not None and new_end is not None and new_end < new_start:
    raise TaskValidationError(
        f"actual_end ({new_end}) must be >= actual_start ({new_start})"
    )

Two problems with adding the same rule in the MCP tool:

1. It is weaker than the domain check. The MCP version only compares the two values passed in the same call. Updating just actual_start to a value after the task's stored actual_end passes the MCP guard; the domain check catches it because it resolves the ... sentinels against the current task state first.
2. It moves away from where fix(ui/mcp): unify fix_actual_times validation (TUI accepts negative duration, MCP accepts end<start) #1143 is heading. That issue is about fix_actual_times validation being implemented three times with three different rule subsets — the stated direction is one shared validator (ideally in core, so the server enforces it too), not a fourth independent copy. This would also split the error surface between ValueError and TaskValidationError.

If you want to pick up #1143, the useful change is consolidating CLI / TUI / MCP onto the core rules — happy to review that.