Update Dispatcher ClientIO interactions

[GeorgeNgMsft]

This PR addresses comments in #2178

Changes :
Explicit client-initiated cancellation (cancelInteraction) instead of auto-cancelling interactions on client disconnect.

PR #2178 (already in main) implemented the async deferred-promise pattern with cancelByConnection — when a client disconnects, all its pending interactions are immediately cancelled. This branch replaces that with:

• Interactions survive disconnect — they remain pending until timeout (10 min) or an explicit call, allowing a reconnecting client to still respond
• New cancelInteraction(interactionId) method on Dispatcher — clients cancel explicitly (e.g. user dismisses UI), not implicitly on disconnect
• Always-log invariant — logPendingInteraction is called unconditionally, even when no clients are connected at broadcast time, so the interaction appears in DisplayLog for session replay

[Copilot]

Pull request overview

This PR updates the agent-server deferred ClientIO interaction flow to avoid implicitly cancelling pending interactions on client disconnect, introducing an explicit client-driven cancellation API and updating interaction queuing/logging behavior for replay.

Changes:

• Adds Dispatcher.cancelInteraction(interactionId) to dispatcher types and RPC client/server plumbing.
• Removes connection-scoped tracking/cancellation from PendingInteractionManager (drops connectionId and cancelByConnection).
• Updates agent-server SharedDispatcher interaction handling and refreshes related tests/docs.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
ts/packages/dispatcher/types/src/dispatcher.ts	Adds cancelInteraction() to the public Dispatcher interface.
ts/packages/dispatcher/rpc/src/dispatcherTypes.ts	Extends dispatcher RPC invoke contract with cancelInteraction.
ts/packages/dispatcher/rpc/src/dispatcherServer.ts	Wires cancelInteraction through the RPC server handler.
ts/packages/dispatcher/rpc/src/dispatcherClient.ts	Adds RPC client method for cancelInteraction.
ts/packages/dispatcher/dispatcher/src/dispatcher.ts	Adds base dispatcher stub that throws for cancelInteraction.
ts/packages/dispatcher/dispatcher/src/context/pendingInteractionManager.ts	Removes connection-based ownership and cancelByConnection; simplifies create().
ts/packages/dispatcher/dispatcher/test/pendingInteractionManager.spec.ts	Updates tests for new create() signature and removes cancelByConnection coverage.
ts/packages/agentServer/server/src/sharedDispatcher.ts	Removes disconnect-driven interaction cancellation; adds explicit cancelInteraction behavior and adjusts queuing/logging behavior.
ts/packages/agentServer/docs/async-clientio-design.md	Updates the design doc to describe explicit cancellation and always-log behavior.

Comments suppressed due to low confidence (1)

ts/packages/agentServer/docs/async-clientio-design.md:82

• The doc says reconnecting clients can respond to pending interactions, but later states JoinSessionResult.pendingInteractions mirrors broadcast eligibility based on requestId.connectionId. Since connectionId is server-assigned per connection and changes on reconnect, those two statements conflict. Clarify the intended routing identity (stable client id vs connection id) and update either the implementation or this doc section accordingly.

Disconnecting a client does **not** automatically cancel pending interactions. Interactions remain pending until they time out or a client explicitly calls `cancelInteraction`. This allows a reconnecting client to respond to the same interaction within the timeout window.

Clients that want to cancel an interaction (e.g., on user dismissal) call `dispatcher.cancelInteraction(interactionId)`, which triggers:

1. `interactionCancelled` broadcast to all clients (so they can dismiss stale UI)
2. An `interaction-cancelled` entry in the `DisplayLog`

### DisplayLog Integration

Three entry types are logged to `DisplayLog`:

- `pending-interaction` — uses `interaction.timestamp` (the creation time of the request, not wall-clock at log time) to keep replay order consistent
- `interaction-resolved` — response is JSON-safe normalized before storage
- `interaction-cancelled`

### Session Join / Reconnection

`JoinSessionResult` includes `pendingInteractions: PendingInteractionRequest[]`, populated by `getPendingInteractions(connectionId, filter)`. This mirrors the `broadcast` eligibility rules exactly — a joining client only receives interactions it would have been sent during normal operation.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.