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

## 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:

```json
{"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`](https://github.com/apache/solr-mcp/blob/main/src/main/java/org/apache/solr/mcp/server/collection/CollectionService.java#L1146):

```java
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:

```bash
docker rm -f && docker run -d --name -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

Start at src/main/java/org/apache/solr/mcp/server/collection/CollectionService.java:1146 and trace the create-collection flow, focusing on effectiveConfigSet and the ConfigSetAdminRequest.Create approach described in the issue. Verify the change with the listed SolrCloud reproduction: each collection should receive a separate configset copy, and fields guessed or added in one collection must not appear in another.

Written by the indexing model from the issue text.