JetStream pull-consumer pagination after a 2.9 to 2.10 upgrade: ephemeral or durable consumers for bounded reads?

Goal

We are moving a NATS JetStream deployment from server 2.9.x to 2.10.x and need to settle on a pagination design for reading a large stream (millions of messages) from a service that answers "give me the next page of history" requests. NATS core has no query or offset/limit semantics, so the plan is to use pull consumer Fetch calls with bounded batch sizes and MaxWait to page sequentially through the stream.

Constraints and uncertainty

The unresolved decision is whether each pagination request should create an ephemeral pull consumer (stateless, but re-reads from a start sequence each time) or share a durable consumer that resumes from its last acknowledged sequence (efficient, but couples concurrent readers to shared ack state). A second concern is that the stream uses limits retention with MaxMsgs and MaxAge, so old messages can be trimmed mid-iteration, and it is unclear how a paged read should detect gaps versus a clean end-of-stream.

We also understand 2.10 changed some JetStream defaults and tightened configuration validation, so existing stream and consumer configs may load differently after the upgrade.

Questions

• For request/response-style pagination, is a durable pull consumer resuming by ack state or an ephemeral consumer starting from an explicit sequence the better documented pattern?
• When retention trims messages during iteration, what is the expected Fetch behavior at the trimmed boundary, and how should a client distinguish a gap from end-of-stream?
• Which stream or consumer configuration fields need re-validation when moving from 2.9.x to 2.10.x?