Please address the comments from this code review:

## Overall Comments
- The pre/post wait_freezes and delay calls are now executed before/after the MaaMsg_Node_Action_Starting/Succeeded|Failed notifications instead of being inside Actuator::run; if external consumers rely on the previous event timing, consider whether these waits should remain around the actual action execution instead of around the notifications.
- Actuator::run has lost the need_to_stop checks around execute_action, while TaskBase::run_action adds them around each Actuator::run; if Actuator::run is used anywhere else, ensure that those callers still get the intended early-stop behavior or reintroduce the checks inside Actuator.
- The repeat handling logic (pre/repeat/post wait_freezes and delays) is now split between TaskBase and Actuator; to keep responsibilities clearer, consider centralizing all timing/wait logic in one layer (e.g., TaskBase) and making Actuator::run a pure single-execution helper with no timing concerns.

## Individual Comments

### Comment 1
<location path="source/MaaFramework/Task/TaskBase.cpp" line_range="142-144" />
<code_context>
-    sleep(pipeline_data.pre_delay);
-
-    auto& rt_cache = tasker_->runtime_cache();
-    ActionResult result;
-
-    for (uint i = 0; i < pipeline_data.repeat; ++i) {
</code_context>
<issue_to_address>
**issue:** Potential use of uninitialized `result` when `data.repeat == 0`.

If `data.repeat` can be 0, the loop won't run and `result` will be used uninitialized when building `cb_detail["action_details"]` and as the function return value, leading to undefined behavior. Please either initialize `result` to a default `ActionResult` or handle the `data.repeat == 0` case explicitly (for example, by returning a default `ActionResult` early).
</issue_to_address>