Revisit: ClustersClient databases/collections caches have no TTL or external-change invalidation

Context

ClustersClient introduced in-memory caches _databasesCache and _collectionsCache to back the new useCached parameter on listDatabases and listCollections, plus public getCachedDatabases / getCachedCollections.

Invalidation happens only on operations driven by the extension itself: dropCollection, dropDatabase, createCollection, createDatabase. If a user creates or drops databases or collections from another tool (shell from a peer process, a different IDE, an admin script), the in-process cache becomes stale until the client is closed and re-opened.

The tree view side is acceptable: users routinely press Refresh. The risk surface is the completion providers that read getCachedCollections() because they will silently miss new collections.

Suggested solutions

1. Add a short TTL (for example 30 to 60 seconds) so the cache self-heals.
2. Hook refreshTreeElement / refreshView commands to also call a public invalidateCaches() on the matching ClustersClient.
3. Listen for cluster level metadata events if the driver exposes them.

Definition of done

• Stale completions for newly created collections are no longer reproducible after a user-visible Refresh.
• Optionally: a chosen TTL is documented in code and selected based on usage data.

Start with src/documentdb/ClustersClient.ts and trace _databasesCache, _collectionsCache, listDatabases, listCollections, and the getCached* methods. Then inspect the refreshTreeElement/refreshView commands and completion providers that consume cached collections. Done means a user-visible Refresh no longer leaves newly created collections missing from completions; document any selected TTL if one is adopted.