Fix approval/user-input events using orchestration ID instead of provider thread ID

[cursor]

What Changed

In ClaudeAdapter.ts, four event emissions in the approval and user-input handlers (handleAskUserQuestion request/resolved and canUseTool request/resolved) were using context.session.threadId as providerThreadId directly, instead of calling providerThreadRef(context) which correctly maps context.resumeSessionId. Replaced all four occurrences with the helper function call.

Why

context.session.threadId is the orchestration-level thread ID, not the Claude SDK's native session ID. Every other event emission in the file correctly uses providerThreadRef(context), which returns context.resumeSessionId. This inconsistency meant approval and user-input runtime events carried an incorrect provider thread reference, breaking observability and any downstream logic correlating events by provider thread ID.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

  

Note

Fix approval and user-input events to use provider thread ID instead of orchestration ID

In ClaudeAdapter.ts, the providerRefs field in emitted runtime events (user-input.requested, user-input.resolved, and canUseTool request/decision events) was using an inline conditional providerThreadId field. These sites now use providerThreadRef(context) to ensure the correct provider thread ID is referenced consistently.

^{Macroscope summarized 241180f.}