fix(feishu): use ReplyMessage instead of CreateMessage for thread delivery

[isheng-eqi]

Fixes #61000

Feishu does not accept receive_id_type=thread_id in CreateMessage — returns error 99992402. When sending a message to a thread (topic) without a specific reply target, use ReplyMessage with reply_in_thread=True instead.

The previous code also had a bug where the CreateMessage request was built but never actually sent because the code fell through to the else block and built a second request.

[alt-glitch]

This was generated by AI during triage.

Fix PR for #61000. Same Feishu thread-delivery symptom ([99992402] receive_id_type=thread_id invalid) as competing open PRs, but a different mechanism: this PR switches the thread-fallback path to ReplyMessage(reply_in_thread=True) so the message stays in the thread, whereas #55067 degrades to chat_id delivery (message reaches the conversation, not the thread) plus a gateway/platforms/base.py reply-anchor, and #39563 preserves reply_to across BasePlatformAdapter + the GatewayRunner media path. Related cluster: #55067, #39563, #9384, and the #39526 thread-routing family. Not a duplicate — flagging the competing mechanisms so a maintainer can pick the canonical fix. (This PR also fixes a latent bug where the CreateMessage request was built but never sent.)

[teknium1]

Thanks for isolating the invalid CreateMessage(receive_id_type="thread_id") path; that branch is still present on current main at plugins/platforms/feishu/adapter.py:4628-4651.

Problems

• The replacement branch passes _thread_id to ReplyMessageRequest.message_id. Main distinguishes topic IDs from reply anchors: tests/gateway/test_feishu.py:2108-2116 supplies thread_id="omt-thread" and reply_to_message_id="om_trigger", then verifies om_trigger is the ReplyMessage target. The PR test instead asserts an omt_topic_abc value is a valid message ID, so it does not demonstrate the new no-anchor call is supported.
• This branch is reached precisely without a reply target, including _standalone_send() which provides only thread_id at plugins/platforms/feishu/adapter.py:5412-5433. The PR needs an explicit valid no-anchor behavior.

Suggested changes

• Keep ReplyMessage limited to a real reply anchor; for a genuinely unanchored thread send, add a tested supported fallback (for example, chat-level delivery), or propagate a valid anchor through the relevant callers.

Automated hermes-sweeper review.

[teknium1]

_thread_id is the topic-routing value in this no-anchor branch, not an established ReplyMessage anchor. Main's Feishu test uses omt-thread for thread_id but sends the reply to a distinct om_trigger ID (tests/gateway/test_feishu.py:2108-2116). Please use a verified message anchor here or implement an explicit supported no-anchor fallback.