fix: deliver the configured mentions in every notification mode

[BobDu]

Fixes #279
Fixes #305

Also addresses item 2 of #282 (see below), and re-opens the question closed by #275.

The mechanism, because the bugs only make sense against it

A DingTalk mention has two halves: the at object decides who gets notified, and a
@<mobile> token in the message body decides where the mention is rendered. Which half you
have to supply depends on the message type, and the plugin treated them as if it did not:

msgtype	what the plugin has to do
markdown / actionCard	append the token. A mobile is never resolved without it, and actionCard needs one for isAtAll too.
text	nothing. DingTalk renders the mention from the at object itself, and appends its own copy even when the body already has one.
link	nothing. DingTalk documents this type as not supporting mentions at all.

Six defects on that path

1. The raw ("disable built-in message") branch never sent at. Its MessageModel was built
   without atAll/atMobiles since raw mode was introduced in c66a0df, so ticking "disable
   built-in message" silently dropped every mention — 禁用内置消息 希望可以有@别人的功能 #279, and item 2 of 希望markdown支持模板语法 #282.

2. "Notify everyone" did nothing on the built-in notification. The built-in message is an
   actionCard, which needs an @所有人 token in the body for isAtAll to take effect, and none was
   ever written. It only worked by accident, when the custom content happened to contain some other
   @ — which is why it behaved intermittently and was never reported on its own.

3. The mention was appended unconditionally, so a template that already mentioned someone got a
   second copy — DingTalk renders both. That is 这个插件发起的通知里面可以把 @被通知人 插入消息中间，而不是结尾吗？ #305.

4. Mobiles were appended even when everyone was being mentioned. DingTalk stops resolving
   individual mobiles once isAtAll is set, so those tokens stayed unresolved: a bare phone number
   sitting in the group message where a name should have been, notifying nobody who was not already
   covered.

5. Text messages got a mention appended as well, which DingTalk renders in addition to the one
   it adds itself.

6. Link messages were given both the at object and an appended @<mobile>. Neither does
   anything for that type — the token is never resolved, so it only left a bare phone number behind.

The mention fields also lived inside the block the UI hides when the built-in message is disabled,
so there was no way to configure them in the mode that now honours them. They move out; the
JavaScript that hides the block is unchanged.

At.isAtAll becomes a primitive so reading it needs no null handling. It is a request object that is
never persisted, and Gson keys off the field name, so the wire format is unchanged.

What changes for users

• Ticking Notify everyone now produces an @所有人 line where there was none, and on the
  built-in notification it notifies reliably instead of occasionally.
• If you ticked Notify everyone and filled in mobile numbers, those numbers no longer appear
  in the message. They were never resolved into names and never notified anyone extra.
• A text message's mention moves onto its own line — that is where DingTalk puts the one it renders.
• Mentions configured for a raw/custom message now work, and the fields to configure them are
  visible in that mode.

Documentation

Mentions in markdown and actionCard messages are not tappable on the DingTalk mobile client.
DingTalk documents the rendering half of this — "机器人发送 Markdown 消息类型@人员，不支持高亮显示",
with a per-type table marking Text 是 / Markdown 否 / ActionCard 否
(robot-message-type-staff-information-in-an-enterprise) —
and testing against a live robot confirms the mention is also not tappable there, while a TEXT
message's mention is tappable on both clients. Using atUserIds instead of a mobile does not change
this: the message type is what decides it, not the identifier.

That is almost certainly what #218 reports. It cannot be fixed inside an actionCard, so this PR
documents it instead of changing behaviour: a new @ 人 page covers how mentions work and what
each message type can do, and the field's own help text plus the two pages that used to promise a
mention without qualifying it now point at it.

Testing done

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

The new tests assert on the JSON actually posted, by pointing the robot's webhook at a local
HttpServer — the first payload-level coverage in this repository:

• DingTalkSenderAtTest covers the token rules — appending, not repeating a token the body already
  has, leaving mobiles out when everyone is mentioned, adding nothing to text or link messages.
• DingTalkRunListenerAtTest runs a real build through JenkinsRule for both notification modes and
  checks the payload carries the configured mention.

Each of the six fixes was checked by mutation: reverting it on its own makes the corresponding test
fail, so the tests reproduce the defects rather than merely exercising the lines.

The behaviour the fixes rely on was established against a live robot rather than inferred — which
message types resolve a mention, whether a token is required, what happens when isAtAll and
atMobiles are combined, and whether wrapping the token in <font> matters (it does not).

Related issues

• Fixes 禁用内置消息 希望可以有@别人的功能 #279 — mentions in raw mode.
• Fixes 这个插件发起的通知里面可以把 @被通知人 插入消息中间，而不是结尾吗？ #305 — the duplicated mention.
• 希望markdown支持模板语法 #282 asks for three things; this PR delivers item 2 (@ALL after disabling the built-in
  message). Item 1 (template syntax in markdown) already works via environment-variable expansion —
  worth confirming with the reporter. Item 3 (deciding whether to notify based on an environment
  variable) is not implemented and deserves its own issue, so 希望markdown支持模板语法 #282 is deliberately not auto-closed.
• 自由风格项目禁用内置消息后如何设置AT通知人 #275 was closed with the advice to write @手机号 into the custom message. That could not work,
  because the raw branch never sent atMobiles — it does now.
• 配置钉钉手机号，at人是假at，没有提醒，不可点击 #218 is addressed by documentation only, for the reason given above.

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