[draft] Limit collections read on tree expansion to a batch with a "load more" item

Summary

When a database node is expanded, the tree currently reads the full list of collections and also starts one background collection-count request per database. For clusters with a very large number of databases or a database with a very large number of collections, this can produce a burst of metadata requests and load a large number of tree items at once.

This issue tracks limiting how many collections we read and render when expanding the tree, so that expansion stays responsive and backend load stays bounded.

Proposed direction (to be defined)

• Read collections in a bounded batch instead of the full list on expansion.
• Render the first batch as tree items, then show a dedicated "Load more" tree item (or a similar affordance) that fetches and appends the next batch on demand.
• Decide the batch size and whether it should be configurable.
• Decide how the "Load more" affordance interacts with the collection-count description on the parent database node (exact vs. capped "N+").
• Apply the same idea to other potentially large listings if it makes sense (for example collections within a database, and databases within a cluster).
• Consider a per-cluster concurrency limiter for background count requests, consistent with the existing document-count limiter, so a large number of databases does not start an unbounded number of concurrent requests.

Context

This came out of review feedback on PR #714 (item counts on tree nodes), where the background collection-count loading starts one request per database with no concurrency limit. The batching and "load more" approach is the broader follow-up and is intentionally left open for design.

Status

Draft. Scope and exact UX are still to be defined.