fix(v2/telegram): await pairing interceptor work to serialize DB commits

The Telegram pairing interceptor fired DB writes (createMessagingGroup,
upsertUser, grantRole) and the pairing-success confirmation inside an
unawaited `void (async () => {...})()`. Recent changes (0d3326a user
privilege model, c483860 pairing confirmation) widened the work done
inside this closure to include an extra two DB writes and a Telegram
API round-trip, making the race between match and commit reproducible
— a paired message could appear "lost" until a second send.

Change onInbound to optionally return a Promise, await it in the
chat-sdk-bridge dispatch callbacks, and make the pairing interceptor
async so its DB writes + confirmation send complete before the handler
resolves.

Note: the upstream @chat-adapter/telegram SDK itself does not await
processUpdate in its polling loop, so the adapter's getUpdates offset
still advances before our handler resolves. A true restart-safe fix
needs a corresponding change in chat-adapter.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

src/channels/telegram.ts

@@ -115,8 +115,8 @@ function createPairingInterceptor(
   hostOnInbound: ChannelSetup['onInbound'],
   token: string,
 ): ChannelSetup['onInbound'] {
-  return (platformId, threadId, message) => {
-    void (async () => {
+  return async (platformId, threadId, message) => {
+    try {
       const botUsername = await botUsernamePromise;
       if (!botUsername) {
         hostOnInbound(platformId, threadId, message);
@@ -187,11 +187,11 @@ function createPairingInterceptor(
       });
 
       await sendPairingConfirmation(token, platformId);
-    })().catch((err) => {
+    } catch (err) {
       log.error('Telegram pairing interceptor error', { err });
       // Fail open: pass through so a pairing bug doesn't break normal traffic.
       hostOnInbound(platformId, threadId, message);
-    });
+    }
   };
 }