feat(routing): route replies to originating channel

Implement reply routing based on OriginatingChannel/OriginatingTo fields.
This ensures replies go back to the provider where the message originated
instead of using the session's lastChannel.

Changes:
- Add OriginatingChannel/OriginatingTo fields to MsgContext (templating.ts)
- Add originatingChannel/originatingTo fields to FollowupRun (queue.ts)
- Create route-reply.ts with provider-agnostic router
- Update all providers (Telegram, Slack, Discord, Signal, iMessage)
  to pass originating channel info
- Update reply.ts to pass originating channel to followupRun
- Update followup-runner.ts to use route-reply for originating channels

This addresses the issue where messages from one provider (e.g., Slack)
would receive replies on a different provider (e.g., Telegram) because
the queue used the last active dispatcher instead of the originating one.

src/signal/monitor.ts

@@ -451,10 +451,11 @@ export async function monitorSignalProvider(
           id: isGroup ? (groupId ?? "unknown") : normalizeE164(sender),
         },
       });
+      const signalTo = isGroup ? `group:${groupId}` : `signal:${sender}`;
       const ctxPayload = {
         Body: body,
         From: isGroup ? `group:${groupId ?? "unknown"}` : `signal:${sender}`,
-        To: isGroup ? `group:${groupId ?? "unknown"}` : `signal:${sender}`,
+        To: signalTo,
         SessionKey: route.sessionKey,
         AccountId: route.accountId,
         ChatType: isGroup ? "group" : "direct",
@@ -468,6 +469,9 @@ export async function monitorSignalProvider(
         MediaType: mediaType,
         MediaUrl: mediaPath,
         CommandAuthorized: commandAuthorized,
+        // Originating channel for reply routing.
+        OriginatingChannel: "signal" as const,
+        OriginatingTo: signalTo,
       };
 
       if (!isGroup) {