Fix BL-16811 Front cover and title page overwrite each other's title padding

[JohnThomson]

Problem

The book title appears on both the front cover and the title page, and both copies carry
bloom-padForOverflow, so when either page opens in the editor Bloom measures the title's
descenders and stores the extra room they need as padding-bottom in the title's style
attribute. The two copies are set at different sizes and so need different amounts: about 3px on
the cover and none on the title page at the default sizes.

Bloom keeps the style attribute of every copy of a data-book field in sync. So the two pages
overwrote each other's padding on every visit, and whichever page was looked at last won. In the
editor you never noticed, because the padding is re-measured on every page load. But the saved
value is what gets published, and BloomPUB, ePUB, Bloom Reader and BloomLibrary render what is in
the file: a book published after visiting the title page last clipped the descenders (g, y, p, j)
of its cover title. As a side effect, the two pages genuinely changed every time they were looked
at, so a merely browsed book showed as modified, and a Team Collection saw spurious checkouts.

Fix

The cover is the one place where this clipping matters, so OverflowChecker now measures the
title's padding only on the outside front cover. The title's other copies inherit the cover's
padding through the normal sync, which costs them a few pixels of extra room and nothing else, and
nothing overwrites the cover's value any more. Padded fields other than the title are still
measured wherever they appear.

This is a deliberate imperfection: the cover's measurement is not exactly right for the title page,
and we are choosing to live with that rather than store one value per page.

Four unit tests cover the new gate: the title on the cover, the title on the title page, a title
on no page, and another padded field on another page.

Ref: https://issues.bloomlibrary.org/youtrack/issue/BL-16811

🤖 Generated with Claude Code

Devin review

---

This change is 

[JohnThomson]

[Claude Fable 5.1 from John Thomson's machine during preflight] Consulted Devin on 2026-09-11 up to commit 90055e64ca7e60fb72ad6209ea40dabdcb5d368b.

It raised one Bug and one Investigate flag, both about decisions already taken: a book whose cover was last saved wrong keeps that value until its cover is opened once here (accepted limit, noted for QA), and the PR targeting master rather than Version6.5 (deliberate: not fixing in 6.5). Both are answered on their threads (bug, flag) and resolved. No informational items. CI (pr-automation) passed; no other review bot has posted.

[hatton]

@hatton made 1 comment.
Reviewable status: 0 of 2 files reviewed, 3 unresolved discussions (waiting on JohnThomson).

---

src/BloomBrowserUI/bookEdit/OverflowChecker/OverflowChecker.ts line 426 at r1 (raw file):

    // If every page measured and stored its own padding, the copies would overwrite each other's
    // value on every visit, and the published book would carry whichever page was looked at last,
    // clipping the cover title when that was the title page (BL-16811). The front cover is where

This should say why that is true. It's not clear at all to me. I think there should be less emphasis on how this problem was fixed and what we are even trying to do here and why. I'm constantly having this problem with Claude.

[JohnThomson]

@JohnThomson made 1 comment.
Reviewable status: 0 of 2 files reviewed, 3 unresolved discussions (waiting on hatton).

---

src/BloomBrowserUI/bookEdit/OverflowChecker/OverflowChecker.ts line 426 at r1 (raw file):

Previously, hatton (John Hatton) wrote…

This should say why that is true. It's not clear at all to me. I think there should be less emphasis on how this problem was fixed and what we are even trying to do here and why. I'm constantly having this problem with Claude.

I actually thought this was one of Claude's better efforts. But I've tried to improve it.