feat(channel): restrict tool approval to the requester in group chats

**Background**

Currently, tool approval requests posted in a group chat can be approved or denied by any member of that chat.

The existing Feishu and Discord implementations report the identity of the user who clicked the approval button. However, the channel gateway resumes the pending tool call without verifying that the actor is the user whose message initiated the current agent run.

As a result, another group member can approve or deny a potentially sensitive tool call on behalf of the requester. In group chats, only the requester should be allowed to resolve tool approval requests triggered by their run.

**Changes**

- Track the originating channel user ID for every channel run triggered by an inbound user message, and carry it through the outbound tool-confirmation flow.
- Validate the platform-authenticated actor of every approval or denial against the originating user before resuming tool execution.
- Apply this rule consistently to all interactive channel implementations (currently Feishu and Discord), and include it in the common channel approval contract for future channel implementations.
- When a different group member clicks an approval button:
- Do not enqueue the confirmation result or resume the run.
- Do not resolve, update, or freeze the shared approval card.
- Show an ephemeral message or toast indicating that only the requester can
approve or deny the tool call.
- Keep the behavior of direct-message conversations unchanged.
- Add tests covering:
- Approval and denial by the requester.
- Approval and denial by a different group member.
- Both `PER_CHAT` and `PER_CHAT_USER` session scopes.
- Stale and duplicate clicks remaining no-ops.

**Note**

- Here, the requester refers to the user whose inbound message started the current agent run. Other users who send hints while that run is in progress do not become approvers.
- The approval policy for scheduled or background runs without a channel-side requester should be defined separately.

Start by locating the common channel approval contract and Feishu/Discord interactive handlers in the gateway flow from inbound user message to tool-call resume. Read existing approval-related tests first, then trace where actor identity is checked before resuming execution and where requester identity must be carried through. Add cases for requester approve/deny, non-requester clicks, PER_CHAT and PER_CHAT_USER scopes, plus stale/duplicate clicks. You’re done when only the originating requester can resolve group-chat approvals, DM runs stay unchanged, and unauthorized clicks produce a no-op or rejection response; then run the channel approval tests.

Escrita pelo modelo de indexação a partir do texto da issue.