fix(bedrock): hoist cachePoint blocks out of ToolMessage content to comply with Bedrock API

[kuzuha]

What this PR does

Fixes Issue #500: Incorrect nesting of cachePoint blocks inside ToolMessage causes Bedrock API request validation errors.

Before (Invalid Bedrock format)

The cachePoint block is nested under toolResult.content, which is not allowed by Bedrock API:

{
  "role": "user",
  "content": [
    {
      "toolResult": {
        "content": [
          {"text": "Tool response"},
          {"cachePoint": {"type": "default"}}  // ❌ Invalid here!
        ],
        "toolUseId": "xyz",
        "status": "success"
      }
    }
  ]
}

After (Valid Bedrock format)

This PR hoists the cachePoint block to be a top-level sibling entry within the message's content array:

{
  "role": "user",
  "content": [
    {
      "toolResult": {
        "content": [
          {"text": "Tool response"}
        ],
        "toolUseId": "xyz",
        "status": "success"
      }
    },
    {
      "cachePoint": {"type": "default"}  // ✅ Valid placement
    }
  ]
}

---

Implementation details

• In _messages_to_bedrock, ToolMessage.content is split into:
  • tool_result_content: Blocks safe to nest under toolResult (e.g., text)
  • special_blocks: Blocks like cachePoint that must be top-level
• Both are placed accordingly in the final Bedrock message structure.

---

Test coverage

Added test_messages_to_bedrock_with_cache_point() in test_bedrock_converse.py to validate:

• Proper splitting of blocks
• Correct nesting according to API expectations

---

Reference

• AWS Bedrock prompt caching spec: https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html#prompt-caching-converse

---

Fixes #500

[michaelnchin]

Thank you @kuzuha !