fix(gateway/feishu): fall back to chat_id routing on stale thread_id (99992402)

[arimu1]

What does this PR do?

Fixes silent message drops when the gateway auto-resumes a session whose
original Feishu thread_id has since been deleted or withdrawn.

_send_raw_message routes using thread_id as receive_id when metadata
contains one. A deleted thread causes Feishu to return 99992402 (field
validation failed). This error was not handled by _feishu_send_with_retry,
so both the primary send and the plain-text fallback silently dropped the
message — observed 53 times in production in one reporter's log.

The fix adds a targeted fallback block: on 99992402 with thread_id in
metadata, strip the stale thread_id and retry with chat_id routing.

Related Issue

Fixes #35576

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✅ Tests (adding or improving test coverage)

Changes Made

• gateway/platforms/feishu.py — new fallback block in _feishu_send_with_retry
• tests/gateway/test_feishu.py — 3 regression tests

Checklist

• Conventional Commits
• No existing PR for this issue
• Tests added and passing
• Blast radius: LOW — isolated to Feishu send retry path only

[tonydwb]

Code Review Summary

Verdict: Approved

Overview

Clean fix for Feishu silent message drops when thread_id is stale (deleted/withdrawn). When _send_raw_message returns error 99992402 with a thread_id present, strips the stale thread_id and retries with chat_id routing.

Looks Good

• Targeted: only triggers on 99992402 + thread_id metadata
• Graceful: strips thread_id, keeps other metadata, retries
• 3 regression tests covering stale thread fallback, no-thread no-retry, and success paths
• Low blast radius: isolated to Feishu send retry path
• Observed 53x in production — real bug fix

---

Reviewed by Hermes Agent

[arimu1]

Friendly ping — this has been approved (tonydwb) with no blocking comments for a few weeks now. Happy to rebase or address anything else needed before merge.

[arimu1]

Second follow-up — still showing as approved (tonydwb) with no further comments since the last ping. Let me know if there's anything else needed on my end before this can be merged.

[teknium1]

Thanks for the focused Feishu recovery path. The premise remains present on current main: _send_raw_message routes a no-reply threaded send through receive_id=thread_id (plugins/platforms/feishu/adapter.py:4626-4635), while _feishu_send_with_retry returns an unsuccessful response when it is outside the existing reply-fallback condition (plugins/platforms/feishu/adapter.py:4798-4825).

The PR-head fallback at plugins/platforms/feishu/adapter.py:4729-4748 is targeted to 99992402 plus thread metadata, preserves unrelated metadata, and retries through the normal chat routing path. Its three tests cover the intended retry and both guard conditions (tests/gateway/test_feishu.py:4962-5025 on PR head).

Automated hermes-sweeper review.