Add Initialize method support for Bedrock client

[willy0416]

Add Initialize method support for Bedrock client

Summary

This PR adds conversation history initialization support to the Bedrock client, enabling users to load and continue existing conversations with proper tool call/result handling.

Problem

Currently, the Bedrock client lacks the ability to initialize conversations with existing message history. This makes it difficult to:

• Resume interrupted conversations
• Load conversation state from storage
• Integrate with systems that maintain conversation history
• Support tool-based workflows that span multiple sessions

Solution

Added comprehensive conversation history initialization support with the following components:

Core Methods

• Initialize(history []*api.Message) error - Loads conversation history into the Bedrock client
• processAPIMessage(msg *api.Message) ([]types.ContentBlock, error) - Converts API messages to Bedrock format
• createToolUseFromPayload(payload map[string]any) (*types.ToolUseBlock, error) - Handles tool call creation
• createToolResultFromPayload(payload map[string]any) (*types.ToolResultBlock, error) - Handles tool result creation

Key Features

• Message Type Support: Handles text messages, tool call requests, and tool call responses
• Tool Call Processing: Properly converts tool calls and results between API and Bedrock formats
• Error Handling: Graceful handling of malformed messages with detailed logging
• Flexible Arguments: Supports both map and JSON string argument formats
• Status Mapping: Converts between API status values and Bedrock tool result statuses

Message Type Mapping

API Message Type	Bedrock Content Block	Description
MessageTypeText	ContentBlockMemberText	User/assistant text messages
MessageTypeToolCallRequest	ContentBlockMemberToolUse	Assistant tool calls
MessageTypeToolCallResponse	ContentBlockMemberToolResult	Tool execution results

Testing

Added comprehensive test coverage with 15+ test cases covering:

• Valid and invalid tool call payloads
• Different argument formats (map vs JSON string)
• Error scenarios and edge cases
• Complex nested result structures
• Message processing with various payload types

Usage Example

// Initialize a conversation with history
history := []*api.Message{
    {
        ID: "msg-1",
        Source: api.MessageSourceUser,
        Type: api.MessageTypeText,
        Payload: "Get all pods",
    },
    {
        ID: "msg-2", 
        Source: api.MessageSourceModel,
        Type: api.MessageTypeToolCallRequest,
        Payload: map[string]any{
            "id": "call-123",
            "name": "kubectl_get",
            "arguments": map[string]any{"resource": "pods"},
        },
    },
    {
        ID: "msg-3",
        Source: api.MessageSourceUser, 
        Type: api.MessageTypeToolCallResponse,
        Payload: map[string]any{
            "id": "call-123",
            "result": map[string]any{"output": "pod1\npod2"},
        },
    },
}

chat := client.StartChat("", "claude-3-sonnet")
err := chat.Initialize(history)
if err != nil {
    log.Fatal(err)
}

// Continue conversation with loaded history
response, err := chat.Send(ctx, "What did you find?")

Backward Compatibility

This change is fully backward compatible. The new methods are additive and don't modify existing functionality.

Related Issues

Fixes the need for conversation history persistence in tool-based workflows.

Checklist

• Added Initialize method to bedrockChat
• Added message processing methods
• Updated documentation
• Verified backward compatibility
• Tested with various message types and payloads

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.