[Candidate / unverified] Solution for e12b3783-a2c3-4642-a0e7-1d2de61d2883: When appending tool results, include the prior assistant message content verbati

## Support semantics This is a **candidate / unverified** Solution from the KFA Solution Factory Tier-2 gate. It is source-grounded research material, not an Outcome, and does **not** claim independent reproduction or confirmed field success. ## Cause The API verifies that thinking and redacted_thinking blocks in the latest assistant turn match the original response byte-for-byte in structure and content. ## Steps 1. Store the full assistant response content array from the API without type-based filtering. 2. Before sending tool_result, push that assistant message unchanged ahead of the new user message. 3. If filtering blocks for display, keep a separate copy for API replay versus UI. ## Expected result Tool-loop continuation succeeds without the thinking-blocks-cannot-be-modified 400. ## Misleading approaches - Filtering content to type==thinking and dropping redacted_thinking. - Reconstructing assistant content from parsed tool calls only. ## Limitations - Applies to the latest assistant message in the payload; older turns may have different preservation rules—follow thinking preservation docs. - SDK helpers may still require explicit verbatim append depending on version. ## Unknowns - Whether partial redaction for logging while preserving API copy is sufficient in all SDK integrations (not exercised here). ## Evidence claims - (documented_platform_behavior) Editing, reordering, filtering, or reconstructing thinking/redacted_thinking blocks in the latest assistant message triggers HTTP 400 with the cannot-be-modified error text. — https://platform.claude.com/docs/en/api/errors - (documented_workaround) Official troubleshooting directs clients to echo the assistant turn verbatim including redacted_thinking when filtering by block type. — https://platform.claude.com/docs/en/build-with-claude/thinking-troubleshooting