Revisit: SchemaStore monotonic accumulation can surface stale fields after external schema changes

Context

ClusterSession.resetCachesIfQueryChanged intentionally no longer wipes accumulated schema data when the user changes the query in the Collection View. Schema data lives in the shared SchemaStore and is accumulated monotonically per (clusterId, databaseName, collectionName).

The trade off is documented in code: preserving field knowledge from earlier queries helps autocompletion when a new query returns zero documents. The risk is that if the collection schema changes externally (drop and recreate, large refactor), completion suggestions will surface fields that no longer exist.

Suggested solutions

1. Add a "Clear Schema Cache" command that targets a single cluster, database, or collection (the global one already exists).
2. Invalidate schema entries for a collection when its underlying ClustersClient.dropCollection succeeds (already partially handled via deleteClient, but not for dropCollection alone).
3. Track sample document _id values and detect a large turnover as a heuristic to age out old field entries.

Definition of done

• A user who recreates a collection externally has a clear, in-product path to refresh schema knowledge.

Start by reading ClusterSession.resetCachesIfQueryChanged and the SchemaStore accumulation behavior. Trace the existing global schema-cache clear command, ClustersClient.dropCollection, and deleteClient to compare current invalidation paths. Done means a user who recreates a collection externally has a clear in-product way to refresh its schema knowledge.