ScrollableResults fetch size on a Hibernate 6 StatelessSession: hint or guarantee?

The goal is to stream a multi-million-row query in Hibernate ORM 6.x using ScrollableResults obtained from a StatelessSession, keeping heap usage flat while the JDBC driver batches rows according to a configured fetch size.

The uncertainty sits at the Hibernate–JDBC boundary. Query#setFetchSize() and hibernate.jdbc.fetch_size are documented as hints, and drivers treat them differently: PostgreSQL streams rows only when autocommit is off, while Oracle applies the hint per statement. StatelessSession holds no persistence context, so Hibernate itself should not buffer entities, but the documentation does not appear to guarantee that a per-query fetch size reaches Statement.setFetchSize() when the query runs as a scrollable cursor, or how ScrollMode.FORWARD_ONLY versus SCROLL_INSENSITIVE affects dialect-specific cursor creation.

Assume Hibernate 6.x with the PostgreSQL and Oracle dialects, read-only iteration, and one transaction held open for the whole scroll.

1. Is a per-query setFetchSize() on a scroll() call guaranteed to reach the JDBC statement in Hibernate 6, or can a dialect or wrapper override it?
2. Does the chosen ScrollMode change the effective fetch size behavior between the PostgreSQL and Oracle dialects?
3. Is there a documented way to confirm the effective fetch size for a scrollable query without enabling driver-level tracing?