BetaCompactionBlockParam.encrypted_content accepted by SDK types but rejected by the live API with "Extra inputs are not permitted"

SDK version: 0.122.0 (also reproduced on 0.117.0)
Beta: compact-2026-01-12 (server-side context compaction)

BetaCompactionBlock (response) and BetaCompactionBlockParam (request) both declare an encrypted_content: Optional[str] field, documented as "Opaque metadata from prior compaction, to be round-tripped verbatim." Per this docstring and the public docs (https://platform.claude.com/docs/en/build-with-claude/compaction), the expected pattern is to append response.content (including any compaction block) directly back into a future request's messages.

Doing exactly that — round-tripping a compaction block returned by the API back into a subsequent request, unmodified — is rejected by the API:

Error code: 400 - {'type': 'error', 'error': {'type': 'invalid_request_error', 'message': 'messages..content.0.compaction.encrypted_content: Extra inputs are not permitted'}, 'request_id': '...'}
This happens both:

Across requests, when replaying stored conversation history that includes a prior compaction block.
Within a single request/turn loop, when a sampling iteration triggers compaction (input tokens crossing context_management.edits[].trigger.value) and the resulting compaction block is appended to messages for the next iteration of the same request.
Repro

Send a request with betas: ["compact-2026-01-12"] and a context_management block with a low input_tokens trigger value, enough conversation/tool-result content to cross it.
The response's content[0] (or wherever compaction lands) is a compaction block with both content and encrypted_content populated.
Append that block verbatim into messages for the next request (per the documented pattern / SDK type).
Next request 400s: messages.N.content.0.compaction.encrypted_content: Extra inputs are not permitted.
Expected

Either:
The API should accept encrypted_content on a replayed compaction block (matching the SDK type and the "round-tripped verbatim" docstring), or
BetaCompactionBlockParam should not declare encrypted_content as a valid request field, and the docs/docstring should clarify that only {type, content} should be sent back.

Workaround:
Stripping encrypted_content from any compaction block before it re-enters a request's messages (both on stored-history replay and on same-request loop continuation) avoids the 400. This works but contradicts the "round-tripped verbatim" docstring and the documented example code, which just does messages.append({"role": "assistant", "content": response.content}) unmodified.