I imagined I wouldn't be hitting the data pages in the db, only the index pages. But I suppose only the hashed key is kept there and not the actual key.

Your example creates a BTree type not a Hash type DB, so there is no "hashed key".

Iterating a cursor in order to collect all the keys effectively means iterating the entire database. The point of cursors is to allow you to iterate the DB without creating such a collection first.

I realise that there are legitimate reasons for collecting the keys--ie. other than for use in subsequently iterating the DB via that collection--but if that is a regular part of your applications requirements, you would do well to keep an "index node" yourself.

This might be as simple as having a recognisable key that will not be a part of your regular keyset, with the associated data item containing the array of keys. That data item might for example be a Storable frozen array which you read once at the beginning of the application, maintain yourself internally as the DB is used and then write back before closing.

Of course, you would be responsible for ensuring that index stayed coherent. Perhaps by including within it some kind of integrity check.