Description

When a Synology Chat DM session is created with dmScope: "per-channel-peer", the session's to field is set to the full peer string "synology-chat:4" rather than just the numeric user ID "4".

When the plugin attempts to send a reply, this value is passed to parseNumericUserId() in src/client.ts. parseInt("synology-chat:4", 10) returns NaN, so user_ids is never set in the payload. The Synology Chat API then returns:

{"error":{"code":800,"errors":"no target"},"success":false}

sendMessage returns false after 3 retries, sendText throws, and the reply is silently lost with no log output indicating a delivery failure.

Steps to Reproduce

1. Configure Synology Chat channel with dmPolicy: "open"
2. Set session.dmScope: "per-channel-peer" (default for local onboarding)
3. Send a message to the bot
4. Agent generates a reply but it is never delivered to Synology Chat

Expected Behavior

Replies are delivered. The numeric user ID should be extracted from the peer string by stripping the channel prefix.

Proposed Fix

In extensions/synology-chat/src/client.ts, update parseNumericUserId to strip the channel prefix before parsing:

function parseNumericUserId(userId?: string | number): number | undefined {
  if (userId === undefined) {
    return undefined;
  }
  // Strip channel prefix (e.g. "synology-chat:4" -> "4")
  const raw = typeof userId === "string" ? userId.replace(/^[^:]+:/, "") : userId;
  const numericId = typeof raw === "number" ? raw : parseInt(raw, 10);
  return Number.isNaN(numericId) ? undefined : numericId;
}

Additional Notes

• The sendText failure is completely silent — no warn/error log is emitted when sendMessage returns false. Adding a log line there would help diagnose this in future.
• The fetchChatUsers auto-block issue (NAS blocking OpenClaw after repeated failed user_list calls during startup) is a secondary problem that compounds this — once auto-blocked, even a fixed parseNumericUserId would fail to resolve user IDs.