CouchDB View Pagination Loses Last-Key Context After Schema Migration

Migrating a CouchDB database to a new schema often changes the keys emitted by a map function. When an application paginates a large view using startkey and limit, it typically stores the last returned key and resumes from that point on the next request.

If the view definition changes between deployments, a previously saved startkey may no longer correspond to a valid position in the updated index. CouchDB does not return a server-managed bookmark for arbitrary view pagination, so the client must track key state itself. It is unclear whether CouchDB 3.x offers any compatibility mechanism for resuming a bounded view query after a schema change, or whether clients must rebuild pagination state from scratch.

What is the supported way to persist a view pagination cursor across schema migrations? Does CouchDB provide a server-side token for bounded view queries that survives index changes? Should applications treat the last key as volatile and re-anchor pagination after every deployment?