fix: checkpoint restore uses current task service before cancellation

[roomote]

This PR attempts to address Issue #10402 where checkpoint restore was not working properly.

Problem

The checkpoint restore was failing because the checkpointRestore message handler in webviewMessageHandler.ts called cancelTask() BEFORE calling checkpointRestore(). This sequence caused:

1. cancelTask() destroyed the current task with its initialized checkpoint service
2. A new task was created with no checkpoint service ready yet
3. When checkpointRestore() was called on the new task, getCheckpointService() returned undefined
4. The restore silently returned early, doing nothing

Solution

Call checkpointRestore() directly on the current task (before any cancellation), which already has its checkpoint service properly initialized. The checkpointRestore function in src/core/checkpoints/index.ts already handles calling cancelTask() internally at the end to reinitialize the UI.

Changes

• Remove premature cancelTask() call in checkpointRestore message handler
• Call checkpointRestore() on the current task directly
• Remove unused pWaitFor import

Testing

• All 25 existing checkpoint tests pass
• TypeScript type checking passes

Feedback and guidance are welcome!

[roomote]

Rooviewer   See task on Roo Cloud

Review complete. No issues found.

The fix correctly addresses the root cause: the old code called cancelTask() before checkpointRestore(), destroying the task's checkpoint service before it could be used. The new approach calls checkpointRestore() on the current task (which has its service initialized), and the function already handles calling cancelTask() internally at the end.

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}