Does Hibernate offset pagination or ScrollableResults scale better for a 10M-row table?

I am working with a Hibernate ORM 6 application backed by a relational database, and one entity table is expected to grow past 10 million rows. A reporting job must read every row once, while the UI only needs small pages of 20 records at a time.

For the UI I currently use a TypedQuery with setFirstResult() and setMaxResults(), which the dialect translates into LIMIT/OFFSET. I understand the database still has to scan and skip rows as the offset grows, so deep pages could get slow. For the batch job I am weighing ScrollableResults against paging through the table in chunks, since loading the full list would exhaust the heap and fill the persistence context.

My uncertainty is how to bound both access patterns correctly:

• At what offset does keyset (seek) pagination become clearly preferable to setFirstResult(), and is that threshold measurable in a dialect-independent way?
• When streaming with ScrollableResults, do I still need periodic session.clear() calls to keep memory flat, or does scrolling alone prevent persistence-context growth?
• Is a unique column in the ORDER BY strictly required to guarantee stable pages across both approaches?