Invalid request: key does not exist – KV v2 list endpoint pagination ambiguity

The goal is to enumerate every key under a large KV v2 path using the /v1/secret/metadata/?list=true endpoint. The current implementation returns a plain keys array with no continuation token, so the caller must rely on prefix filtering to simulate pagination. Performance degrades noticeably with more than ~1,000 entries, and there is no documented cap on the number of keys returned per request.

When a non‑existent path is queried, the response is an error: Invalid request: key does not exist. It is unclear whether this error could also surface when the list operation is implicitly truncated by an internal limit, or if it only signals a truly missing path. ACL policies may hide keys, potentially masking the truncation.

Unresolved questions:

• Does the KV v2 list endpoint impose an internal maximum number of keys returned for a single request, and if so, what is that limit?
• Is there a documented or configurable way to discover or adjust this internal limit?
• Could the Invalid request: key does not exist error be triggered by an internal truncation rather than a truly missing path?