feat(runtime): preflight native PDF inputs against provider document constraints #3284

Problem

#3164 adds the first provider-native PDF materialization path with provider/wire gating and raw-binary budgets. That slice intentionally does not parse PDF structure before dispatch.

The remaining local boundary is deterministic document validation. A canonical Attachment may declare application/pdf while the provider still rejects it because it is encrypted, password-protected, malformed, or over a provider-specific page limit. Anthropic currently requires a standard unencrypted PDF and limits the total pages in one request; OpenAI requires a real PDF MIME/type and applies file/request limits.

Desired outcome

Before raw PDF bytes enter a verified provider request, Maka performs bounded, deterministic validation for the constraints it can establish locally. Rejected inputs remain durable attachments but degrade to a short provider-visible explanation; their bytes never enter the model request.

Proposed scope

1. Introduce a bounded PDF metadata inspection boundary owned below AiSdkBackend. It should report at least:
   • whether the bytes are structurally a PDF;
   • whether the document is encrypted or password-protected;
   • page count when it can be determined safely;
   • a typed validation failure without extracted document text.
2. Preserve the storage-sniffed MIME through AttachmentByteReader (or an equivalent authority) so declared metadata cannot relabel another binary type as a PDF.
3. Carry provider-specific document constraints in the explicit PDF input contract rather than scattering model/provider conditionals through materialization.
4. Apply Anthropic's current standard-PDF, encryption, and request-page requirements using the resolved context window.
5. Cache inspection by immutable Artifact identity/content so current Turn, replay, steering, compaction replacement, and provider steps do not repeatedly parse the same durable occurrence.
6. Keep inspection bounded in CPU, memory, recursion, and malformed-object handling.

Acceptance criteria

• A valid unencrypted PDF under the applicable limits still materializes through the feat(runtime): materialize native PDF inputs for verified PDF-capable providers #3164 native path.
• An encrypted/password-protected PDF is not sent and produces a bounded explanation.
• A binary whose declared metadata says PDF but whose sniffed content is not PDF is not sent.
• An Anthropic request exceeding the applicable total page limit is not sent.
• Inspection failures do not copy PDF bytes or extracted text into transcripts, RuntimeEvents, logs, diagnostics, or telemetry.
• Current Turn and durable replay make the same validation decision for the same immutable Artifact.
• Focused malformed/encrypted/page-boundary tests run without external provider credentials.

Non-goals

• OCR, PDF text extraction, rendering, repair, or decryption.
• Uploading documents to a third-party Files API.
• Retrying a provider request after a remote PDF rejection; track that separately.
• Expanding native PDF support to unverified compatible providers.

References

• Parent delivery: feat(runtime): materialize native PDF inputs for verified PDF-capable providers #3164
• Anthropic PDF requirements: https://platform.claude.com/docs/en/build-with-claude/pdf-support
• OpenAI file inputs: https://developers.openai.com/api/docs/guides/file-inputs

Disclosure: this issue was drafted with OpenAI Codex assistance and reviewed and approved by the human contributor.