Merge order for the rebased PR queue (verified conflict-free for 13 of 15)

All the open PRs authored by me are now rebased on `main` (`a84033b`) and individually green. But they are **not independently mergeable** — several touch the same files, so merging them in an arbitrary order stalls on conflicts roughly every second merge.

This issue records an order that has been **empirically verified**, not reasoned about: I replayed candidate orders as real merges onto `a84033b` and measured which conflicted.

## The overlap that causes it

| File | PRs competing for it |
|---|---|
| `CollectionService.java` | #103, #108, #110, #111 |
| `SchemaService.java` | #98, #108, #110 |
| `SearchService.java` | #108, #110, #164 |
| `IndexingService.java` | #108, #110 |
| `build.gradle.kts` | #104, #35, #136 |

#108 (collection-name validation) and #110 (SLF4J logging) are the hubs — between them they touch all four service classes.

## Recommended order

Merging in this sequence, **13 of these merge with zero conflicts**:

| # | PR | Area |
|---|---|---|
| 1 | #175 | `JsonResponseParser` — empty-facet fix |
| 2 | #99 | `SearchResponse` |
| 3 | #104 | `solr.url` validation |
| 4 | #105 | document-creator blank input |
| 5 | #162 | MCP server instructions |
| 6 | #174 | release workflow fixes |
| 7 | #143 | docs site *(still blocked on the dev@ discussion — skip if unresolved; it conflicts with nothing)* |
| 8 | #53 | spec doc *(draft)* |
| 9 | #111 | narrow metrics catch clauses |
| 10 | #103 | `CollectionService` visibility |
| 11 | #164 | typed `SortClause` |
| 12 | #108 | unified collection-name validation |
| 13 | #136 | cut 1.0.0 *(per @epugh, this goes to `branch_1_0_0`, not `main`)* |

**Verified:** with those 13 merged together, `./gradlew build` is green on JDK 25 — **415 tests, 0 failures, 7 skipped**. So the sequence is not just conflict-free, it is semantically consistent.

## The two that need a rebase, and why

- **#110 (SLF4J logging)** — conflicts on `CollectionService` + `SearchService` whatever the order. It adds logging *inside* the same catch blocks #108 and #111 modify, so it is inherently last-mover. I'll rebase it once #108 lands.
- **#98 (`getSchema` throws clause)** — conflicts with #108 on `SchemaService`. Six lines; trivial rebase. One of #98/#108 must move, and #108 is the larger change, so #98 is the cheaper one to rebase.

Ordering alternatives I measured, for the record:

| Order | Clean | Needed rebase |
|---|---|---|
| **Recommended (above)** | **13** | #110, #98 |
| Isolated first, hubs last | 13 | #108, #110 |
| Hubs (#108, #110) first | 12 | #98, #111, #164 |
| #110 before the singles | 12 | #111, #164, #98 |

Two rebases appears to be the floor — #110 and one of #98/#108 conflict pairwise no matter what.

## Separately: #35 vs #136

These collide **by design** and it is not an ordering problem. Both rewrite the same line in `build.gradle.kts`: #136 pins `version = "1.0.0"`, #35 replaces it with `version = semver.version` (git-semver-plugin). Manual pin vs. automatic derivation — whichever lands second needs a deliberate re-resolve, not a mechanical rebase. Per the discussion on #35, the plan is 1.0.0 first, tag it as the semver baseline, then #35. #35 is in any case parked behind getting one real release out.

## Not in this list

- **#23** (Spring Boot 4 / Spring AI 2.0) — parked behind the 1.0 release; rebased and green (372 tests) but deliberately out of the queue.
- **#86**, **#144**, **#159** — other contributors'. #144 and #159 are waiting on merge PRs I opened against their forks (shahzadarain/solr-mcp#3, y-luis-rojo/solr-mcp#2).

Happy to do the #110 and #98 rebases as soon as their predecessors land — just ping me, or they can be done in a batch at the end.

Start by reviewing the listed PR order and the overlap table, especially the conflicts involving #108, #110, and #98. Run ./gradlew build after each integration step; done means the applicable rebases or merges are conflict-free and the build remains green.

Written by the indexing model from the issue text.