Use a discriminated union for type-safe narrowing

PluginConversationBindingResolvedEvent is a flat type with binding?: PluginConversationBinding and decision: PluginConversationBindingResolutionDecision. This means TypeScript won't prevent plugin authors from accessing event.binding as possibly undefined when event.status === "approved", and won't narrow out "deny" from decision when the status is "approved". The internal PluginBindingResolveResult already models this correctly with a discriminated union, and the public contract should follow the same pattern.

With this shape, narrowing on event.status === "approved" will guarantee event.binding is defined and exclude "deny" from event.decision, and narrowing on "denied" will guarantee event.decision === "deny" — consistent with how PluginBindingResolveResult is already typed internally.

This is a comment left during a code review.
Path: src/plugins/types.ts
Line: 960-976

Comment:
**Use a discriminated union for type-safe narrowing**

`PluginConversationBindingResolvedEvent` is a flat type with `binding?: PluginConversationBinding` and `decision: PluginConversationBindingResolutionDecision`. This means TypeScript won't prevent plugin authors from accessing `event.binding` as possibly `undefined` when `event.status === "approved"`, and won't narrow out `"deny"` from `decision` when the status is `"approved"`. The internal `PluginBindingResolveResult` already models this correctly with a discriminated union, and the public contract should follow the same pattern.

```suggestion
export type PluginConversationBindingResolvedEvent =
  | {
      status: "approved";
      binding: PluginConversationBinding;
      decision: Exclude<PluginConversationBindingResolutionDecision, "deny">;
      request: {
        summary?: string;
        detachHint?: string;
        requestedBySenderId?: string;
        conversation: {
          channel: string;
          accountId: string;
          conversationId: string;
          parentConversationId?: string;
          threadId?: string | number;
        };
      };
    }
  | {
      status: "denied";
      binding?: never;
      decision: "deny";
      request: {
        summary?: string;
        detachHint?: string;
        requestedBySenderId?: string;
        conversation: {
          channel: string;
          accountId: string;
          conversationId: string;
          parentConversationId?: string;
          threadId?: string | number;
        };
      };
    };
```

With this shape, narrowing on `event.status === "approved"` will guarantee `event.binding` is defined and exclude `"deny"` from `event.decision`, and narrowing on `"denied"` will guarantee `event.decision === "deny"` — consistent with how `PluginBindingResolveResult` is already typed internally.

How can I resolve this? If you propose a fix, please make it concise.

Missing allow-always callback coverage

The two new tests cover allow-once approval and deny, but the allow-always decision path through resolvePluginConversationBindingApproval is not exercised by the new callback tests. allow-always takes a slightly different code path — it first calls addPersistentApproval before bindConversationNow — so a dedicated test confirming the callback fires (and carries decision: "allow-always") after the persistent-approval write would complete the regression suite and guard against a future regression where, for example, an early return or exception inside addPersistentApproval silently skips the notification.

This is a comment left during a code review.
Path: src/plugins/conversation-binding.test.ts
Line: 350-406

Comment:
**Missing `allow-always` callback coverage**

The two new tests cover `allow-once` approval and `deny`, but the `allow-always` decision path through `resolvePluginConversationBindingApproval` is not exercised by the new callback tests. `allow-always` takes a slightly different code path — it first calls `addPersistentApproval` before `bindConversationNow` — so a dedicated test confirming the callback fires (and carries `decision: "allow-always"`) after the persistent-approval write would complete the regression suite and guard against a future regression where, for example, an early return or exception inside `addPersistentApproval` silently skips the notification.

How can I resolve this? If you propose a fix, please make it concise.

Run resolution callbacks off the approval hot path

resolvePluginConversationBindingApproval now waits for each registered onConversationBindingResolved handler, so a slow plugin callback (for example, network I/O) can stall approval handling long enough to miss interaction deadlines. This is user-visible because channel handlers await resolvePluginConversationBindingApproval before completing their response flow (e.g., Discord/Telegram button handling), so approvals can succeed internally while the user sees timeout/failed-interaction errors; callback execution should be detached or time-bounded so it cannot block the approval response path.

Useful? React with 👍 / 👎.

Move resolution callbacks off the approval hot path

Awaiting registration.handler(event) here puts arbitrary plugin work (including network I/O) directly on the approval response path. Fresh evidence: Discord, Telegram, and Slack each await resolvePluginConversationBindingApproval(...) before sending their interaction acknowledgements (extensions/discord/src/monitor/agent-components.ts:860, extensions/telegram/src/bot-handlers.ts:1232, extensions/slack/src/monitor/events/interactions.block-actions.ts:480), so one slow callback can push the response past platform deadlines and produce timeout/failed-interaction UX even when the approval itself succeeded.

Useful? React with 👍 / 👎.

Defer callback dispatch past interaction-ack continuation

dispatchPluginConversationBindingResolved now uses queueMicrotask, but that still runs before the caller resumes after await resolvePluginConversationBindingApproval(...); in the Discord/Telegram/Slack approval handlers that means plugin callback code executes before the interaction acknowledgement path. If a plugin callback does synchronous work (or chains sync-heavy handlers before its first await), approvals can still hit timeout UX even though binding succeeded, so this should be moved to a macrotask-style detachment (setImmediate/setTimeout(0)) or another fully off-path dispatcher. Fresh evidence is the new queueMicrotask(...) scheduling added here, which preserves pre-ack execution order.

Useful? React with 👍 / 👎.

Schedule resolution callbacks after caller continuation

Using queueMicrotask here still keeps plugin callback execution on the interaction-ack critical path: Discord/Telegram/Slack all await resolvePluginConversationBindingApproval(...) before sending their acknowledgement/update, and microtasks queued inside this function can run before those callers resume. In environments where a plugin handler does synchronous work (or substantial pre-await CPU work), approvals can still miss platform response deadlines even though the bind decision succeeded, so this needs a true off-path dispatch (e.g., macrotask/background queue) rather than a microtask.

Useful? React with 👍 / 👎.