First PDPageAddNewAnnot on a large old-version PDF takes 60–170 s (one-time, then instant) — same freeze with Acrobat's native Stamp tool. What one-time work is Acrobat doing?

I'm developing an Acrobat Pro DC plug-in (C++, Acrobat DC SDK) that adds custom annotations. On certain large, old-version PDFs (10,000–25,000 pages), the first annotation added to the document blocks the UI for 60–170 seconds. Every subsequent add is ~1 ms. It's strictly one-time per document session.

Crucially, the same freeze reproduces with Acrobat's own native Stamp/Comment tool — so this does not appear to be specific to my plug-in's code, but to Acrobat's core annotation-add path on these documents.

Where the time goes (instrumented with std::chrono around each SDK call):

PDPageCreateAnnot : 0 ms
PDPageAddAnnot    : 68,982 ms      <-- the entire cost is here
(2nd annotation)  : PDPageAddAnnot : 1 ms

So the cost is entirely in PDPageAddAnnot (equivalently the second half of PDPageAddNewAnnot), i.e. the insertion into /Annots plus the PDPageWillAddAnnot/PDPageDidAddAnnot broadcast — not in creating the annotation. A pure Cos-level insert into the page's /Annots array (bypassing PDPageAddAnnot) completes in ~4 ms, but the annotation is then not registered in Acrobat's PD-layer annotation list and never renders.

Document profile at open (PDDocGetFlags + Cos inspection):

pages          = 10,000
PDDocIsLinearized = false
PDDocIsOptimized  = false
PDDocOldVersion   = true          (flags = 0x2080)
/AcroForm present = yes, but 0 top-level fields
total annotations = 37
No /StructTreeRoot (document is not tagged)

Things I've tested and ruled out (each had no effect, or made it worse):
- Tagging / structure tree — document has no /StructTreeRoot; temporarily detaching it made no difference.
- AcroForm — temporarily detaching the catalog's /AcroForm around the add made no difference (times unchanged).
- Linearization (Fast Web View) — flag is clear; and re-saving the file without Fast Web View made it worse (~168 s).
- It is not annotation count (only 37) and not form-field count (0).

My questions:
1. What one-time, document-wide work does Acrobat perform on the first PDPageAddAnnot in a document, and why would it be O(pages) on a large old-version PDF (page-tree rebuild? cross-reference/annotation model construction? something reacting to the PDPageDidAddAnnot broadcast)?
2. Is there an SDK-supported way to pre-trigger / warm this one-time cost (e.g., at DocOpened), or to add an annotation that Acrobat renders and hit-tests without incurring it? (I understand Acrobat is single-threaded, so a background thread isn't an option.)
3. Does the PDDocOldVersion flag / an unbalanced page tree explain this, and does rebuilding the document (PDF Optimizer / save to a newer version) eliminate it? Is there a programmatic way to detect the offending structure and/or rebuild it from a plug-in?
4. Which notification recipient does the heavy work on PDPageDidAddAnnot, and can it be suppressed for non-widget custom annotations?

Environment: Acrobat Pro DC (Continuous), Windows, Acrobat DC SDK, C++ plug-in.