[Fix-18677][master] Null-safe taskExecuteType in task finish logging and default it to BATCH on save

[wank125]

Was this PR generated or assisted by AI?

YES — the fix, the regression test and this description were drafted with AI assistance (Claude-based coding agent). The bug was discovered while operating a production DolphinScheduler 3.2.2 deployment; the change was reviewed locally by the submitter (the service module compiles and passes spotless locally; the master module could not be built in the submitter's network environment due to an unrelated dependency range resolution issue, so CI validation is relied upon for it).

Purpose of the pull request

Fixes #18677

Task definitions created via the export → import round trip can carry taskExecuteType = null (exported JSON has no such field, import does not default it, and the DB column has no default value). When such a task finishes:

WorkflowInstanceUtils#logTaskInstanceInDetail -> NPE (getTaskExecuteType().getDesc() on null)
-> state event retried 4x, all fail -> dropped
-> task instance stuck in RUNNING forever, workflow instance never completes,
   master re-dispatches the shell repeatedly

A pure logging helper thus has the power to crash the task finish chain. Verified on a production 3.2.2 deployment: 48 imported task definitions with task_execute_type NULL reproduced the stuck state deterministically; fixing the data restored normal completion immediately.

Brief change log

• WorkflowInstanceUtils#logTaskInstanceInDetail: render null taskExecuteType as N/A instead of throwing — a logging helper must not be able to take down the task finish event chain
• ProcessServiceImpl#saveTaskDefine: default a missing taskExecuteType to BATCH, so task definitions saved from workflow import (and any other caller) never persist null

Verify this pull request

This change added tests and can be verified as follows:

• Added testLogTaskInstanceInDetailWithNullTaskExecuteType to WorkflowInstanceUtilsTest: invoking the log helper with a null taskExecuteType no longer throws and renders N/A
• End-to-end verification was performed on a 3.2.2 deployment as described in the issue (deterministic reproduction before, immediate recovery after the data fix)