Adding the first annotation to a very large legacy PDF stalls for 1–3 minutes (once per document, instant thereafter) — and it reproduces with Acrobat's built-in Stamp tool. What is Acrobat computing on that first add?

I maintain an Acrobat Pro DC plug-in (C++, Acrobat DC SDK) that places custom annotations. With some very large, legacy-version PDFs (roughly 10,000–25,000 pages), placing the very first annotation freezes the UI for around 60–170 seconds. From the second annotation onward it's ~1 ms. The delay happens exactly once per opened document.

What makes me think this isn't my plug-in: the same multi-minute stall happens when I use Acrobat's own native Stamp/Comment tool on these files. That points at Acrobat's core annotation-insertion path rather than my code.

Timing I captured (std::chrono around each SDK call):

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

The whole delay sits in PDPageAddAnnot (i.e. the second half of PDPageAddNewAnnot) — the /Annots insertion and the synchronous PDPageWillAddAnnot/PDPageDidAddAnnot broadcast — not in creating the annotation. If I instead insert the annotation object into the page's /Annots array directly at the Cos level (skipping PDPageAddAnnot), it finishes in ~4 ms, but the annotation is never picked up by Acrobat's PD-layer annotation list and therefore doesn't render.

Document characteristics at open (PDDocGetFlags plus 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 (the document is not tagged)
                                                                                                                                                          What I've already tried and eliminated (no improvement, or wor
- Structure tree / tagging — there's no /StructTreeRoot; temporarily removing it changed nothing.
- AcroForm — temporarily removing the catalog's /AcroForm around the add made no difference at all.
- Linearization (Fast Web View) — the flag is already clear, and re-saving the file without Fast Web View actually made it slower (~168 s).
- It correlates with neither annotation count (only 37) nor form-field count (0).                                                                         
What I'm hoping to understand:
1. On the first PDPageAddAnnot in a document, what one-time, document-wide work does Acrobat carry out, and why would it scale with page count on a large legacy PDF (page-tree reconstruction? building an annotation/cner reacting to PDPageDidAddAnnot)?
2. Is there a supported way to warm this cost up front (say, during DocOpened), or to add an annotation Acrobat will render and hit-test without paying it? (I realize Acrobat is single-threaded, so offloading to a worker thread isn't viable.)
3. Could the PDDocOldVersion flag / an unbalanced page tree beding the file (PDF Optimizer, or saving to a newer version)remove it? Is there a way to detect the problematic structure — and rebuild it — from within a plug-in?
4. Which notification handler performs the expensive work on Pe any way to skip it for non-widget custom annotations?

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