fix(beta): omit compaction encrypted_content on request round-trip

[lllakshit]

Summary

• Strip encrypted_content from compaction blocks during request serialization so messages.append(response.content) no longer 400s with Extra inputs are not permitted.
• Add src/anthropic/lib/_compaction.py (non-generated) and hook it into transform / async_transform after Stainless TypedDict handling.
• Clarify compaction block docstrings and add respx-backed regression tests for dict/model round-trips, batch params, and web-search/advisor blocks that legitimately keep encrypted_content.

Fixes #1828.

Test plan

• uv run pytest tests/lib/test_compaction_request.py tests/lib/streaming/test_beta_messages.py tests/test_transform.py::test_transform_skipping -q
• uv run ruff check on changed files
• uv run pyright / uv run mypy on changed files

[lllakshit]

Hi @anthropics/sdk, this is a small request-side fix for #1828: compaction blocks include encrypted_content in responses, but sending it back on the next request 400s. The strip lives in src/anthropic/lib so it should survive Stainless regeneration, with regression tests for the round-trip and for blocks that should keep encrypted_content.

I just rebased onto current main. Happy to adjust if you want a different approach.

[dineshyadav03]

Read through the diff. omit_compaction_encrypted_content recursively walks the transformed payload (dicts/lists/tuples), stripping encrypted_content only when type == 'compaction'. It's hooked in after _transform_recursive/_async_transform_recursive in both sync and async transform, so the field is stripped uniformly regardless of whether the caller passed a BetaCompactionBlock model or a raw dict — confirmed by test_transform_strips_compaction_dict_on_create_params, which asserts the Stainless-generated transform still copies the field, and this wrapper is what removes it afterward. That's a solid regression guard against the behavior silently changing on a future OpenAPI regen.

Coverage looks reasonable: web-search/advisor blocks with their own encrypted_content are correctly left untouched, cache_control and null content survive stripping, and there's a nested batch-params test. One thing I didn't see: the match is purely structural (type == 'compaction' + key presence), not tied to the actual param type, so any future block that happens to reuse that discriminator would also get silently stripped — probably fine given the namespace, but worth a one-line comment documenting the assumption.

Approve.