fix(channels): route handoff reply ack by channel

[Caldalis]

Intent

/回复反馈 (alias /handoff_reply) is dispatched on every channel, but the acknowledgment it stages hard-codes a Feishu-shaped delivery target (receive_id/receive_id_type). WeCom and WeChat read to_user_id, DingTalk reads session_webhook, so on those three the ack is undeliverable: the handoff resolves, the assignee gets no confirmation, and a failed delivery is left behind. WeCom is hit hardest — it is in HANDOFF_NOTIFY_CHANNELS, and the notification it sends tells the assignee to reply with this exact command.

Changes

• Pass the channel target the caller already resolved (staged ChannelInboundEvent.target_json, or the process_inbound fallback for WeChat) into _run_handoff_reply_command and use it for the ack, as every other command reply does.
• Record source=binding.channel instead of a hard-coded "feishu".
• Follows the per-channel target handling introduced in feat(handoff): route assignee notifications by channel #200; this path was missed.

Risk

On Feishu the ack now replies to the command message instead of sending a new DM, since the staged target carries message_id. This matches every other Feishu command reply. The identical hard-coded target in _stage_feishu_assignee_reply is left alone — it is only reachable inside the binding.channel == "feishu" branch.

Tests

New test_channel_handoff_reply.py (11 cases): per-channel ack target and recorded source, plus a guard asserting the WeCom/WeChat/DingTalk adapters reject a Feishu-shaped target. Updated the 7 existing call sites in test_feishu_handoff.py. Full suite 2008 passed (1997 before); ruff check clean on changed files.

UI Validation

Not applicable — backend channel intake only, no route or role affected.
No existing issue; found while auditing channel capability parity.