add generic PDF object-tree writers for page and annotation dicts

[jchatkinson]

Summary

Adds a generic serialized object-tree writer for unsupported PDF dictionary writes in EmbedPDF.

This PR introduces low-level write support for:

• page dictionaries
• annotation dictionaries

Motivation

This provides a low-level escape hatch for writing valid PDF spec fields that are not currently exposed by EmbedPDF’s typed APIs.

Examples this unlocks:

• page /VP viewport dictionaries
• nested /Measure structures
• richer fields on existing annotation subtypes
• other unsupported page/annotation dictionary keys without requiring a new wasm export for each individual field

What Changed

@embedpdf/models

• Added PdfObjectSpec to describe serialized PDF object trees
• Added setPageDictValue(...)
• Added setAnnotationDictValue(...)

@embedpdf/engines

• Wired the new methods through the orchestrator, remote executor, web worker engine, and PDFium engine
• Added PdfObjectSpec serialization for:
  • null
  • boolean
  • number
  • string
  • name
  • array
  • dict
• Added dictionary-key validation
• Added an annotation appearance-regeneration allowlist for keys likely to affect rendering

@embedpdf/pdfium / PDFium

• Added EPDFPage_SetDictValue(...)
• Added EPDFAnnot_SetDictValue(...)
• Parse serialized direct PDF object syntax with CPDF_SyntaxParser
• Reject indirect refs and stream objects in the current implementation
• Treat top-level null as delete/remove for the target key

Scope

This PR is limited to the generic write primitive.

It does not add:

• manual appearance stream (/AP) authoring
• stream-object support
• indirect-reference support

Validation

Validated with:

• package builds for models, pdfium, engines, and downstream annotation packages
• export/reopen tests from my local implementation using the new generic writer path
  -- Tested page /Rotate, adding /CL to freetext.
• external viewer verification that unsupported keys persist and affect viewer behavior

One important testing outcome:

• dictionary writes and persistence work
• appearance-driven features may still require stronger AP regeneration or typed feature support for full compatibility.

Follow-up Work

Possible follow-ups after this primitive:

• possible future stream/AP-specific support if needed

[vercel]

@jchatkinson is attempting to deploy a commit to the OpenBook Team on Vercel.

A member of the Team first needs to authorize it.