chore: scrub external project references from wecom comments

mateclaw-server/src/main/java/vip/mate/channel/wecom/WeComKeepaliveScheduler.java

@@ -20,7 +20,7 @@ import java.util.concurrent.TimeUnit;
  * the eventual {@code finish=true} chunk is silently rejected — the
  * user sees "🤔 思考中..." stuck forever. RFC-32 §2.1.2 (R-7 / B-5).
  *
- * <p><b>Constants</b> (verified against QwenPaw {@code channel.py:66-67,986-1031}):
+ * <p><b>Constants</b> (chosen empirically based on observed slot lifetime):
  * <ul>
  *   <li>20s refresh interval — well under the observed 60s minimum drop</li>
  *   <li>180s force-finish ceiling — bound the worst-case "stuck" UX even

mateclaw-server/src/main/java/vip/mate/channel/wecom/cards/tool_guard/ToolGuardButtonKey.java

@@ -18,11 +18,10 @@ import java.util.Map;
  * minimal context we need to recover the pending approval (the
  * {@code pendingId} alone is enough — mateclaw's
  * {@code ApprovalService.findById} resolves the rest, including the
- * original requester). QwenPaw's approach also stuffs sender/chat
- * context for offline-render reasons; mateclaw doesn't need that
- * because the inbound handler runs in-process and can do a synchronous
- * DB lookup, leaving headroom in the 1024-byte budget for long
- * tool names / Chinese characters.
+ * original requester). Sender/chat context is intentionally not packed
+ * — the inbound handler runs in-process and can do a synchronous DB
+ * lookup, leaving headroom in the 1024-byte budget for long tool names
+ * / Chinese characters.
  *
  * <p>Encoding is stable (LinkedHashMap → consistent key order so byte-
  * length is predictable). Decoding tolerates extra fields — useful if

mateclaw-server/src/main/java/vip/mate/channel/wecom/cards/tool_guard/ToolGuardCardRenderer.java

@@ -12,8 +12,7 @@ import java.util.Map;
  * Build the WeCom {@code button_interaction} approval card payload from
  * an {@link ApprovalNotice}.
  *
- * <p>Card structure (verified against QwenPaw {@code tool_guard.py:107-140}
- * + WeCom official protocol):
+ * <p>Card structure (matches the WeCom official protocol):
  * <pre>
  * {
  *   "card_type": "button_interaction",