Header image renders oversized in display mode (overlays body content)

[jedrazb]

Reported during manual testing of PR #264 (which fixes save round-trip for header images, issue #251). This bug is pre-existing — surfaces now that save works.

Repro

1. bun run dev, open http://localhost:5173/
2. Load any DOCX with a header (e.g. e2e/fixtures/titlePg-header-footer.docx).
3. Double-click the header to enter edit mode.
4. Paste an image (Cmd+V) — image renders at sane size in edit mode.
5. Click outside the header to exit edit mode.

Expected: Image stays at the same size; body content shifts down to make room.

Actual: Image renders much larger and overlays body text below the header.

Investigation breadcrumbs

The infrastructure to handle this exists but isn't producing the right result:

• PagedEditor.tsx:1842-1844 already extends effectiveMargins.top when headerContentHeight > availableHeaderSpace. So body should be pushed down.
• measureParagraph.ts:601-603 already includes inline image height (run.height) in line height via currentLine.maxImageHeightPx.
• calculateHeaderFooterVisualBounds() at PagedEditor.tsx:1294 aggregates paragraph measure heights into visualBottom.

Suspected causes:

1. Measurement cache staleness — when the header's PM doc changes (image inserted), the convertHeaderFooterToContent measurement may be using cached data that doesn't include the new image.
2. The <img> clipping hack at renderPage.ts:1149-1151 disables overflow:hidden for headers containing any <img>. That's intended for floating images, but it also fires for inline images (which shouldn't need the clip-disable). If effectiveMargins.top extension fails for any reason, the disabled clip lets the image visually overflow into body.
3. Possible width vs. height mismatch between PM toDOM and painter renderInlineImageRun:
   • PM ImageExtension.ts:82-91 writes max-width: 100% + CSS width/height
   • Painter renderParagraph.ts:319-339 writes only HTML width/height attributes, no max-width

Reproduction artifact

Screenshots attached in PR #264 conversation (issue #251 follow-up).

Estimated fix

Small-to-medium. Likely a one-line fix once root cause is confirmed in DevTools, but root cause needs live inspection.