fix: log the payload that is actually sent to DingTalk

[BobDu]

What this fixes

The 发送的消息详情 (message details) line of the build log is the only place a user can see what the plugin actually posted to DingTalk. It has been logging the wrong object since the raw notification mode was added in c66a0df (2023-03).

Before that commit, the local variable message was the MessageModel, and the log line was correct. c66a0df needed a variable for the user's custom template and reused the same name for it, renaming the model to msgModel. Two call sites had to follow, and only one of them did:

String message = item.getMessage();                 // new: the raw template
MessageModel msgModel = item.isRaw() ? ... : ...;   // renamed: the payload

DingTalkUtils.log(listener, "发送的消息详情，%s", Utils.toJson(message));   // silently kept the old name
String msg = service.send(robotId, msgModel);                             // had to be updated

send(String, MessageModel) rejected a String, so the compiler forced that one. Utils.toJson(Object) accepted it, so the log line kept compiling with entirely different meaning. The result:

• a built-in notification logs literally 发送的消息详情，null, because the template field is unset when the built-in message is used;
• a raw notification logs the template before variable expansion, not what was sent.

Every DingTalkUtils.log call is gated on the global verbose setting, so this line only reaches the build log once someone turns detailed logging on — which is exactly when they are trying to diagnose a delivery problem and get null instead.

Nothing is lost by pointing it at the payload: the preceding 当前机器人信息 line already logs the notifier configuration, raw template included.

The local variable is renamed to rawMessage in the same change. That is what removes the trap rather than just its symptom: there is no longer a message in this scope for a future rename to collide with.

Testing done

mvn clean verify passes: 58 tests, plus spotless, access-modifier-checker, the enforcer import rules and spotbugs (0 findings).

DingTalkRunListenerLogTest runs a real build through JenkinsRule against a robot pointing at a closed port, then asserts on the build log — one case for the built-in message, one for a raw template. Both assert the log carries the expanded payload, which is what distinguishes it from the configuration line above it.

Both cases were checked by mutation: restoring Utils.toJson(message) makes them fail with [钉钉插件]发送的消息详情，null in the captured log, so they reproduce the reported behaviour rather than merely exercising the line.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed