fix(confirm): fast-scroll long disclosures

[BitHighlander]

Summary

• replace the generic Cut Off warning with renderer-backed pagination for complete long confirmation bodies
• start scrolling after a 300 ms hold, advance at 120 ms per page, and pause immediately when the button is released
• require a release and a fresh confirmation hold after the final page, so scrolling through the end cannot approve by itself
• route exact-byte message disclosures through the same scrolling engine while retaining escaped whitespace/control bytes and page counters
• fail closed if formatting already lost source bytes, and fix the renderer boundary that previously counted a rejected final glyph as displayed

Validation

• pinned kktech/firmware:v15 complete emulator build and ctest: 78/78 firmware, 11/11 board, and 4/4 crypto tests passed
• release-style arm-none-eabi build linked firmware.keepkey.elf successfully
• cppcheck completed with zero findings
• merge base verified as release/7.14.2 at d1204ed

Hardware review

Please verify the 300 ms initial delay, 120 ms page cadence, pause-on-release behavior, page counters, and the mandatory fresh final hold on a physical KeepKey OLED. The existing rc30 Cut Off hardware steps describe the superseded warning flow and should not be used as the acceptance UX for this PR.

[BitHighlander]

Superseded by #488 for the paging design, which is merged to release/7.14.2.

This PR and #488 solve the same problem with different input models:

#480 hold 300ms to start, auto-advance every 120ms, pause on release
#488 one short click per page, full hold only on the last page

We took the click model. On a single button, an auto-advancing page is a timing
race the user cannot pause precisely, and the failure mode is advancing past
something you were still reading. A click is discrete and self-paced.

Both PRs enforce the property that matters -- scrolling to the end cannot
approve by itself. #488's is hardware-measured: a tap on the final page yields
15s of silence, a hold yields Success at 1.650s
(docs/release/rc30-evidence/T13-pager-hardware.md).

Credit where due: this PR was first, and I did not check open PRs before writing
#488. That is on me.

Two things here are worth keeping and are NOT in #488 -- filing them rather than
letting them die with this branch:

1. routing confirm_bytes() through the same paging engine, so SignMessage and
   generic confirmations share one implementation instead of two
2. the unittests/board/board.cpp coverage

The draw.c boundary fix from this branch already landed separately as #481 and
was confirmed on hardware during the rc30 round (the fit boundary is 118
characters).