fix(annot): drop Apple Markup's stale copy when a page's annotations change

[Kiwi-Kwi]

What this changes

A page signed with iOS Markup carries Apple's private copy of its markup: /AAPL:PPK and /AAPL:PPKHash on the page, and /AAPL:AKExtras on each Markup annotation. After PdfCraft adds a signature to such a page, iOS (seen on iOS 26.6.1) displays the Markup signature twice: in its own place and over the signature PdfCraft added. Every other viewer we tried, PdfCraft included, renders the file correctly. The saved PDF is valid; Apple is drawing from its now-stale private copy.

set_annots is the single place where a page's annotation list changes (add, delete, reply, links, inline-dict promotion). It now removes those three keys from the page and from the page's annotations first, so Apple falls back to drawing every annotation from its appearance stream, as other viewers do. The Markup annotation itself, its /AP and its flags are kept, and Apple keys are only touched when present (no extra objects in an incremental save otherwise).

How you verified it

On a real document (signed with iOS Markup, then signed in PdfCraft 0.8.0), opened on an iPhone:

variant	iPhone shows
as saved by 0.8.0	Markup signature twice ❌
page /AAPL:PPK + /AAPL:PPKHash removed	Markup signature twice ❌
page keys and the annotation's /AAPL:AKExtras removed (what this PR does)	both signatures correct ✅
PdfCraft signature flattened	both signatures correct ✅

So the page-level keys alone are not enough; /AAPL:AKExtras has to go too.

• cargo fmt --check (-p pdfcraft-annot)
• clippy with -D warnings: cargo clippy -p pdfcraft-annot --all-targets -- -D warnings
• tests pass: cargo test -p pdfcraft-annot (43 passed)
• cargo xtask layers / assets: not applicable, no crate boundary or asset touched

Tests. New unit test adding_to_an_apple_markup_page_drops_apples_stale_copy (synthetic fixture shaped like an iOS Markup page). Seen failing with the drop_apple_markup call reverted, passing with it. End-to-end: a pdfcraft-cli run script (doc_open, fill_sign_add image signature, doc_save) on the real file leaves no AAPL: keys behind, and both stamps survive.

Never-crash

• No new unwrap/expect/panic!/unreachable!/todo! outside tests
• No indexing or slicing with input-derived positions; no input-sized allocation; no recursion
• No unsafe
• Not a crash fix

Provenance

• No assets, no fonts
• No GPL/AGPL code
• Behaviour from black-box observation of the file and of iOS rendering, not from another implementation's source
• No new assets

Security

• No path handling touched
• MCP / control channel untouched
• No network access

Parity and reach

• parity/ not updated: interop fix, not a feature
• Reachable headlessly through the existing fill_sign_add / comment_add / stamp_custom tools
• No documented behaviour changes

Anything a reviewer should look at first

• This drops data (the fidelity rule). The keys are Apple's private, regenerable cache of what /Annots already holds; keeping them is what produces the wrong rendering. The cost is that iOS can no longer re-edit the Markup strokes as live ink; they stay as their normal appearance. The iOS stamp in the report is /F 644 (Locked + LockedContents) anyway. If you'd rather record the drop somewhere (a warning on the edit result?), I'm happy to add it.
• Only list-changing edits trigger it (set_annots). Moving or restyling an existing Markup annotation leaves the stale copy, which could show the old position on iOS. I kept the change minimal rather than guess at that case without a repro.
• cargo test -p pdfcraft-engine was not run locally (CI runs the workspace).

🤖 Generated with Claude Code

[ahmadmuj]

Could the removal record a fidelity warning, given the reported loss of live ink editing? Adding one note removes the Apple data across the page, but leaves repair_log empty.

There is also a low-level rejection case: set_style on an inline locked stamp returns "the comment is locked" after removing the private keys. Please defer removal until validation succeeds. The engine currently protects failed user edits by discarding its copy.

Synthetic save/reopen checks preserve exact appearance bytes, resources, flags, and stamp pixels across eight variants. The committed regression could include an appearance stream too; its stamp currently has no /AP. I could not test iOS.