fix: add checkpoints at task start, attempt_completion, and mode switch

[roomote]

Summary

This PR addresses Issue #8458 by adding checkpoints at three critical points in the task lifecycle to enable easy reverting of changes.

Changes

• Task Start: Added checkpoint creation when a task begins to allow reverting to the initial state
• Attempt Completion: Added checkpoint when attempt_completion is called to mark the task completion state
• Mode Switch: Added checkpoint before mode switches to preserve state before mode transitions

All checkpoints use:

• allowEmpty=true to ensure checkpoint creation even without file changes
• suppressMessage=true to keep the timeline clean and avoid UI clutter

Testing

• ✅ All existing tests pass
• ✅ Linting passes
• ✅ Type checking passes
• ✅ Manual testing confirms checkpoints are created at the expected points

Review Confidence

Code review confidence: 85% (HIGH)

• Implementation correctly addresses all requirements
• Code follows established patterns
• No security concerns identified

Future Improvements

Consider adding specific unit tests for checkpoint creation at these trigger points to ensure the behavior is maintained.

Fixes #8458

---

Important

Add checkpoints at task start, attempt completion, and mode switch to enable state reverting, with options to ensure creation and suppress UI messages.

• Checkpoints:
  • Added checkpoint at task start in Task.ts to revert to initial state.
  • Added checkpoint in attemptCompletionTool.ts when attempt_completion is called to mark task completion.
  • Added checkpoint in switchModeTool.ts before mode switch to preserve state.
• Checkpoint Options:
  • All checkpoints use allowEmpty=true to ensure creation without file changes.
  • All checkpoints use suppressMessage=true to avoid UI clutter.

^{This description was created by for c9ea9fc. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Self-review: auditing my own code like a mirror test that calls introspect().

[roomote]

P2 — Avoid blocking the task loop: checkpointSave() is designed to run in the background; awaiting here delays the first API call. Fire-and-forget to keep startup responsive.

Suggested change

	await this.checkpointSave(true, true)
	void this.checkpointSave(true, true)

[roomote]

P2 — UX latency: awaiting checkpoint here blocks the mode switch on git I/O. Consider non-blocking; the checkpoint will still be recorded, and the mode switch remains snappy.

Suggested change

	await cline.checkpointSave(true, true)
	void cline.checkpointSave(true, true)

[daniel-lxs]

Fixed