A2A invoke does not support CUSTOM_JWT authentication

[aidandaly24]

Description

The A2A invoke path (invokeA2ARuntime in src/cli/aws/agentcore.ts lines 857-915) has no bearer token support. The A2AInvokeOptions interface doesn't include a bearerToken parameter, so if a user configures an A2A protocol agent with authorizerType: CUSTOM_JWT, every invoke will use SigV4 and fail with "Authorization method mismatch."

This is a feature gap — the HTTP and MCP invoke paths both support bearer tokens, but A2A was not updated to match.

Steps to Reproduce

1. Add an agent with A2A protocol and CUSTOM_JWT:

   agentcore add agent \
     --type byo \
     --name myA2AAgent \
     --protocol A2A \
     --authorizer-type CUSTOM_JWT \
     --discovery-url $DISCOVERY_URL \
     --allowed-clients $CLIENT_ID \
     --client-id $CLIENT_ID \
     --client-secret $CLIENT_SECRET

2. Deploy: agentcore deploy -y
3. Invoke: agentcore invoke "hello"

Expected Behavior

The CLI should either:

• Auto-fetch a bearer token and pass it to the A2A invoke path (like HTTP/MCP do), or
• Reject the configuration at add agent time with a clear error: "A2A protocol does not support CUSTOM_JWT authentication"

Actual Behavior

The invoke silently uses SigV4 and fails with "Authorization method mismatch" — same silent fallback as #814 but in a different code path.

Additional Context

The A2AInvokeOptions interface at src/cli/aws/agentcore.ts needs a bearerToken parameter, and invokeA2ARuntime needs a bearer token dispatch similar to what invokeAgentRuntimeStreaming does at line 289:

if (options.bearerToken) {
  return invokeWithBearerTokenStreaming(options);
}

The TUI invoke flow at src/cli/tui/screens/invoke/useInvokeFlow.ts line 322-336 also doesn't pass bearerToken to the A2A path, only to the streaming HTTP path.

Related: #814