feat: 清洗任务增加重试次数记录和日志展示

[hhhhsc701]

No description provided.

In general, user-controlled data used in path expressions should be constrained so that the resulting path cannot escape an intended base directory or become an absolute path. A common and robust pattern is: (1) define a base directory as a Path, (2) resolve the user input as a child path using base.resolve(userInput), (3) normalize the result, and (4) verify that the normalized result still starts with the base directory. If any check fails, reject the request.

For this specific case, we should treat FLOW_PATH as the root of all cleaning task logs, and ensure that taskId cannot break out of that directory. Instead of using String logPath = FLOW_PATH + "/" + taskId + "/output.log"; and Paths.get(logPath), we should build a Path like:

Path baseFlowPath = Paths.get(FLOW_PATH).toAbsolutePath().normalize();
Path logFilePath = baseFlowPath.resolve(taskId).resolve("output.log").toAbsolutePath().normalize();
if (!logFilePath.startsWith(baseFlowPath)) {
    throw new BusinessException(SystemErrorCode.ILLEGAL_ARGUMENT, "Invalid taskId");
}

Then use Files.lines(logFilePath) and in the error logging use logFilePath.toString(). This preserves existing functionality (log files still live under FLOW_PATH/<taskId>/output.log[.retry]) while ensuring that even if taskId contains .. or separators, the normalized path is checked against the base directory before reading. We can keep the existing cleanTaskValidator.checkTaskId(taskId); call; the new checks are an additional defense-in-depth and the direct mitigation for this CodeQL alert.

We only need to adjust the getTaskLog method in CleaningTaskService and slightly change the imports to use java.nio.file.Path instead of java.nio.file.Paths directly where appropriate. No changes are required in CleaningTaskController.