[chcmedeiros]

Follow-up to #237, which closed the truncation hole but paid for it in density.

The cost #237 left behind

v52.1.0 sizes the chunk so that no arrangement of characters can overflow a review page, by assuming every character is as wide as the widest glyph the font can draw (31px on Stax). That is always safe and almost always wrong. Hex and bech32 run about 19 characters to a line, so a page carried 110 characters where it had room for 159, and filled six of its ten lines.

Measure the item instead of assuming the worst

Start from what the value buffer holds and shrink until no page of that item overflows its lines, asking the same question NBGL asks when it breaks its own details pages — how much of this text fits in this many lines at this width (nbgl_getTextMaxLenInNbLines). Cached per item next to the page count, so the search runs once per review.

Measured on Stax, 200-character values:

content	chars per page	lines used	complete
hex / bech32	110 → 159	6 → 9	200/200
digits	110 → 159	7 → 10	200/200
wide glyphs	110 (unchanged)	10	200/200

Nothing is truncated in any of them. The search is constrained by the same fit check that #237 introduced, and #237's budget remains the floor whenever the search cannot settle. The per-page guard stays as the backstop.

For the apps

ledger-cosmos comes back byte for byte. The wasm_boundary_test snapshots return to exactly what they were before v52.1.0 split them across an extra page — verified with cmp, 6 pages, 0 differing frames. So for this app the security fix becomes invisible to normal content, and the snapshot churn #237 caused is undone rather than blessed.

Full suite, all five devices: 179 of 183, the four being the three expected wasm_boundary_test page-count reverts plus one Timeout waiting to connect that passes on re-run.