fix: propagate sessionId as A2A contextId in Inspector proxy

[kashinoki38]

Description

Fixes a bug where the Agent Inspector Chat UI (agentcore dev) did not propagate the session identifier into the A2A Message.contextId field. As a result, every turn against an A2A agent arrived with a freshly-generated contextId, and any agent-side session manager keyed on the A2A contextId (e.g., Strands FileSessionManager(session_id=context.context_id)) started a new empty session per turn, breaking multi-turn memory.

The Inspector frontend already tracks a sessionId per conversation and forwards it to the dev-server proxy. The HTTP-protocol branch of handleInvocations correctly maps this to the x-amzn-bedrock-agentcore-runtime-session-id header, but the A2A branch (handleA2AInvocation) silently dropped it when constructing the JSON-RPC body.

This PR maps sessionId to the A2A Message.contextId field when present.

Change

 const a2aBody = {
   jsonrpc: '2.0',
   id: a2aRequestId++,
   method: 'message/stream',
   params: {
     message: {
       messageId: randomUUID(),
       role: 'user',
       parts: [{ kind: 'text', text: prompt }],
+      ...(sessionId ? { contextId: sessionId } : {}),
     },
   },
 };

A2A spec compliance

Both branches of the conditional are compliant with the A2A Protocol Specification:

• When sessionId is present → the client sends contextId to indicate continuation. Per §3.4.3 Multi-Turn Conversation Patterns: "Clients MAY include the contextId in subsequent messages to indicate continuation of a previous interaction."
• When sessionId is absent → the message omits contextId. Per §3.4.1 Context Identifier Semantics: "Agents MAY generate a new contextId when processing a Message that does not include a contextId field."

Field naming (contextId, camelCase) also matches §5.5 JSON Field Naming Convention.

Scope

One-line change, A2A branch of handleA2AInvocation only. The HTTP and AGUI branches are not touched.

Related Issue

Closes #891

Documentation PR

N/A — this is a runtime bugfix with no user-facing API or config change; the Inspector already exposes sessionId in the frontend, and A2A agents already accept contextId per spec. No docs update is required.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Test results

• npm run typecheck: clean (0 errors)
• npm run lint: 0 errors, 11 warnings — all pre-existing, in files unrelated to this change (HelpScreen.tsx, tui-harness/mcp/server.ts)
• npm run test:unit: ✅ Ran — no regressions introduced by this PR.
  • Baseline on main (v0.9.1, commit f2de452): 9 failed / 3306 passed (231 files)
  • After this change: same pre-existing flaky failures (tui-harness/__tests__/proof-of-concept.test.ts, dev/__tests__/dev.test.ts positional prompt invoke, mcp/__tests__/AddGatewayJwtConfig.test.tsx). None exercise handleA2AInvocation.
  • There are no direct unit tests for this handler in the current codebase (src/cli/operations/dev/web-ui/__tests__/ only contains mcp-proxy.test.ts).
• npm run test:integ: ❌ Not run — requires AWS credentials that are not configured in this environment.
• Manual E2E: Built locally via npm run build, linked via npm link, and confirmed with a local Strands A2AServer using FileSessionManager(session_id=context.context_id):
  • Turn 1: "My name is Taro" → agent responds and stores state under the server-generated contextId.
  • Turn 2: "What is my name?" → agent responds "Your name is Taro", confirming contextId is forwarded across turns.
  • Agent-side logs confirm the same context_id=<sessionId> is received on both turns.

I did not add automated tests as part of this PR because (a) there is no existing test infrastructure for handleA2AInvocation in the repo, and (b) per project conventions in CONTRIBUTING.md, I kept the change minimal. Happy to add tests in a follow-up if the maintainers would like.

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works — see note above; manually verified end-to-end.
• I have updated the documentation accordingly — N/A, no docs affected.
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published