create-collection binds every collection to the shared _default configset, leaking schema between collections

[adityamparikh]

Summary

create-collection binds each new collection directly to the shared _default configset instead
of giving it its own copy. Because _default has data-driven (schemaless) mode enabled, the first
collection's guessed field types are written into the shared managed-schema in ZooKeeper, and
every collection created afterwards inherits them.

Since Solr field types cannot be modified once created, the second collection is permanently stuck
with the first one's guesses.

Reproduction

Solr 9, SolrCloud, empty cluster.

1. create-collection        name=shows-auto
2. index-json-documents     collection=shows-auto   (schemaless guessing runs)
3. create-collection        name=shows
4. add-fields               collection=shows        (explicit types)

Step 4 fails:

error processing commands, errors: [{add-field={name=title, type=text_general, ...},
errorMessages=[Field 'title' already exists.]}, {add-field={name=platform, type=string, ...},
errorMessages=[Field 'platform' already exists.]}, ...]

get-schema on the brand-new, never-indexed shows collection returns step 2's guesses:

{"name": "platform",     "type": "text_general"}
{"name": "imdb_rating",  "type": "pdoubles"}
{"name": "release_year", "type": "plongs"}

CLUSTERSTATUS confirms the sharing:

shows       -> configName: _default
shows-auto  -> configName: _default

The leak runs in both directions — create a collection with an explicit schema first, and a later
collection silently inherits those types instead, so it is not schemaless at all.

Root cause

CollectionService.java:1146:

CollectionAdminRequest.createCollection(name, effectiveConfigSet, effectiveShards, effectiveRf)
        .process(solrClient);

with effectiveConfigSet defaulting to _default. This attaches the collection to that configset
by reference.

For contrast, bin/solr create -c foo -n _default copies _default into a new configset named
after the collection, which is why the same sequence works from the CLI.

Suggested fix

Have create-collection upload a per-collection copy of the source configset (e.g. via
ConfigSetAdminRequest.Create with baseConfigSetName) and point the new collection at the copy,
matching bin/solr create behaviour. The explicit configSet parameter should keep its current
meaning of naming the base to copy from.

Impact

Two distinct failures, neither of which points at the real cause:

1. add-fields fails with Field 'x' already exists on a collection that was just created and
   never indexed. The message gives no hint that another collection is responsible.
2. Schema silently leaks across collections. A collection can end up with field types nobody
   defined for it, and because types are immutable, there is no recovery short of recreating the
   configset or the cluster.

The natural MCP workflow — "create a collection, then set up its schema", which the built-in
setup-collection and design-schema prompts both encourage — hits this whenever more than one
collection exists.

Workaround

Restart Solr (or otherwise reset _default) between collections. For a single container:

docker rm -f <container> && docker run -d --name <container> -p 8983:8983 solr:9-slim solr start -c -f

Environment

• main @ a84033b; CollectionService.java unmodified at that commit
• Solr 9 (solr:9-slim), SolrCloud mode with embedded ZooKeeper
• solr-mcp 1.0.0-SNAPSHOT, Spring Boot 3.5.14