fix: ignore face-attached text when matching wake prefix

[tangtaizong666]

Fixes #9341.

When a QQ yellow-face emoji is sent from the mobile client, some OneBot implementations (SnowLuma v1.12.5, NapCat ≤ 4.17.x) serialize it as a face segment plus a text segment holding the face's display name, e.g. [face:475] + "/干饭". Since message_str is built by concatenating only text segments, such a message produces message_str = "/干饭", which starts with the default wake prefix / — so a plain emoji message falsely wakes the bot and triggers an LLM reply.

WakingCheckStage already guards against a related case (first segment is an At to someone else), but any other non-text leading segment slipped through. The wake prefix should only match text the user actually typed at the head of the message, not text attached to a leading face segment.

Modifications / 改动点

• astrbot/core/pipeline/waking_check/stage.py: in the wake-prefix branch, locate the first message segment that is not a leading At/Reply. If that segment is a Face, the prefix match comes from face-attached text rather than a user-typed command, so the prefix does not wake the bot. All other wake paths (@bot, reply-to-bot, private chat, plugin handler filters) are untouched.
• tests/test_waking_check_stage.py: new unit tests covering the regression and guarding against over-reach:
  • [Face(475), "/干饭"] (group) → no wake ✅ (the reported bug)
  • [Reply, Face(475), "/干饭"] (replying to a member with an emoji) → no wake ✅
  • [Face(475), "/干饭"] in private chat with friend_message_needs_wake_prefix → no wake ✅
  • ["/help"], [Image, "/ocr"] (image pasted, then command typed), [At(bot), "/help"], ["/help", Face] → still wake, prefix stripped as before ✅

The scope is deliberately narrow: only a leading face segment suppresses the prefix match, so commands that carry media (e.g. an image pasted before /ocr) and trailing emojis keep working exactly as today. The desktop client serializes the same emoji as [干饭] (no / prefix), which never matched a wake prefix and is unaffected.

• This is NOT a breaking change. / 这不是一个破坏性变更。

Screenshots or Test Results / 运行截图或测试结果

Verification steps

1. Construct the exact message shape reported in the issue ([face:475] + text "/干饭", as logged by the reporter: [表情:475] /干饭) and run it through WakingCheckStage with wake_prefix = ["/"].
2. Before the fix, the reported case wakes the bot; after the fix it does not, while typed-command cases keep waking.

RED — on current master, the new tests reproduce the bug (3 failing cases are the false wakes):

$ uv run pytest tests/test_waking_check_stage.py -q
FAILED tests/test_waking_check_stage.py::test_face_attached_text_does_not_wake
FAILED tests/test_waking_check_stage.py::test_reply_then_face_attached_text_does_not_wake
FAILED tests/test_waking_check_stage.py::test_private_face_attached_text_needs_no_false_wake
3 failed, 4 passed, 1 warning in 2.76s

GREEN — with the fix:

$ uv run pytest tests/test_waking_check_stage.py -q
7 passed, 1 warning in 2.50s

Full local CI-style validation (make pr-test-neo):

==> Running Ruff format check
482 files already formatted
==> Running Ruff lint check
All checks passed!
==> Running pytest
............                                                             [100%]
12 passed, 1 warning in 4.36s
==> Starting smoke test on http://localhost:6185
==> Smoke test passed
==> PR checks completed successfully

Neighboring pipeline-stage tests also pass (tests/test_preprocess_stage.py, tests/test_rate_limit_stage.py, 10 passed total with the new file).

---

Checklist / 检查清单

• 😊 If there are new features added in the PR, I have discussed it with the authors through issues/emails, etc.
  / 如果 PR 中有新加入的功能，已经通过 Issue / 邮件等方式和作者讨论过。

• 👀 My changes have been well-tested, and "Verification Steps" and "Screenshots" have been provided above.
  / 我的更改经过了良好的测试，并已在上方提供了“验证步骤”和“运行截图”。

• 🤓 I have ensured that no new dependencies are introduced, OR if new dependencies are introduced, they have been added to the appropriate locations in requirements.txt and pyproject.toml.
  / 我确保没有引入新依赖库，或者引入了新依赖库的同时将其添加到 requirements.txt 和 pyproject.toml 文件相应位置。

• 😮 My changes do not introduce malicious code.
  / 我的更改没有引入恶意代码。

Summary by Sourcery

Prevent wake-prefix detection from triggering on QQ face-attached text while preserving normal command wake behavior.

Bug Fixes:

• Stop group and private messages consisting of a leading face emoji plus attached text from incorrectly waking the bot.

Tests:

• Add WakingCheckStage regression tests for face-attached text in group and private messages and for valid command scenarios to ensure wake behavior remains correct.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[Soulter]

hi，下面的情况是否也会被 break

[QQ表情] 你好 @xxxx

[tangtaizong666]

不会的。这里的 break 只是跳出唤醒词匹配循环，不影响后面的 At 检测分支——该分支会扫描消息链中所有段，只要有 @机器人 / @全体 / 引用机器人消息就照常唤醒。

分两种情况：

• [QQ表情] 你好 @机器人：唤醒词路径确实会 break（第一个内容段是表情），但随后 At 分支检测到 @机器人，正常唤醒，与改动前行为一致；
• [QQ表情] 你好 @其他人：不唤醒——这正是 [Bug]qq黄脸表情会触发 / 唤醒词 #9341 要修的场景。前导的 /表情名 是 OneBot 实现附带的表情文本而非用户输入的指令，改动前这种消息会被 / 前缀误唤醒。

已补两个回归测试覆盖这两种情况（fae7dfe1）：test_face_text_then_at_bot_still_wakes、test_face_text_then_at_other_does_not_wake。后者在未修复代码上会失败（误唤醒），前者验证 At 唤醒不受影响。