Issue Description:
When using the iMessage channel with imsg provider, there is a critical bug where messages sent by the agent (replies) are being read back from the Messages database and treated as new inbound messages. This creates an infinite loop where each user message triggers two database entries: one is_from_me=0 (received) and one is_from_me=1 (sent by agent), with both appearing as separate messages.

Steps to Reproduce:

1. Configure OpenClaw with iMessage channel (binding agent to imessage:default)
2. Send a message via iMessage to the configured number
3. Observe that for each user message, two identical messages appear in the chat history - one from user and one from agent, with the same timestamp
4. The agent's reply gets read back as a new inbound message, causing continuous looping

Expected Behavior:

• Agent should only process inbound messages (is_from_me=0)
• Sent messages (is_from_me=1) should be ignored by the inbound message watcher
• Each user message should result in exactly one agent reply

Actual Behavior:

• Every user message results in the agent sending a reply
• That reply is immediately read back as a new inbound message
• This creates duplicate entries in the database and effectively a message loop
• The gateway log shows repeated "delivered reply" messages without actual new inbound triggers

Configuration:

channels:
  imessage:
    enabled: true
    cliPath: /opt/homebrew/bin/imsg
    dbPath: /Users/.../Library/Messages/chat.db
    dmPolicy: allowlist
    allowFrom: ["+8613500199099"]
    defaultTo: "+8613500199099"
    groupPolicy: allowlist

bindings:
  - agentId: main
    match:
      channel: imessage
      accountId: default

Workaround:
Temporarily removed the iMessage binding from the config to stop the loop. Users can still interact via other channels (Feishu, webchat, etc.).

Environment:

• OpenClaw: 2026.3.8
• imsg: 0.5.0 (built from source on 2026-03-10)
• macOS: 26.3.1 (arm64)
• Database: Messages/chat.db (standard macOS Messages database)

Additional Notes:
Database query shows paired records:

ROWID | date | text | is_from_me
5452  | ...  | 你好  | 1  (sent by agent)
5453  | ...  | 你好  | 0  (received from user)

Both have identical timestamps and text content, confirming the loop.

The iMessage provider needs to filter out messages where is_from_me=1 when watching for new inbound messages, similar to how other channels (e.g., Feishu) handle deduplication.