emrg: an @ inside a Feishu thread wakes nothing and is never read #2623

A host was @-mentioned in a reply inside a thread on Feishu. Nothing woke the Feishu task, and the round that did eventually run did not report the message: the host found it themselves.

Two independent gaps, one per side of the task.

1. The wake condition reads only the top level. emrg/server/wake.py's _condition_feishu lists each conversation with im +chat-messages-list and then iterates _message_items(reply), calling _needs_the_host(message, ...) once per entry. That command answers a thread as its parent message carrying the replies in a thread_replies key, and no code in emrg/ reads that key at all (measured on master 28c822b7: grep -rn 'thread_replies' emrg/ answers nothing). So an @ the host received inside a thread is invisible to the condition, which answers absent and leaves the task asleep for its whole interval.

2. The task's prompt never asks a round to expand a thread. emrg/server/feishu_prompt.md §1 says to read each conversation and to skip what the task itself sent, and says nothing about replies hanging under a message. A round woken by something else would still miss the @ for the same reason — the data arrives with the listing, and the instruction to look at it does not exist.

What the fix must satisfy

• _condition_feishu applies the same test to a message's thread_replies as to the message itself, so an @ to the host inside a thread holds the condition exactly as a top-level @ does. No extra CLI call: the replies arrive with the listing.
• A reply is de-duplicated by its own message id, so a thread read twice in one lookback window is still one message.
• A reply that mentions nobody, or that the task itself sent, must not hold the condition — a wake that fires on every threaded conversation is worse than one that misses, because it costs a round every interval.
• emrg/server/feishu_prompt.md §1 states it in the section that owns reading: a message's replies are part of that conversation, and an @ to the host written inside a thread is a message to the host, wherever it sits.
• Regression cases cover both directions on each side — the condition holding and not holding, and the template carrying the requirement in the file and in the prompt a round is actually rendered.