feat(collection): added alias management

[y-luis-rojo]

feat(collection): add alias management tools (list, create, delete)

[adityamparikh]

Thanks @y-luis-rojo for the contribution. Seems like a useful capability to add.
Added inline comments as well as overall comments to address:

1. Looks like the happy path in unit tests need actual assertions.
2. Please add an AliasServiceIntegrationTest that uses Testcontainers to test adding, updating, removing aliases on a new or existing collection.
3. Please update the docs with this new tool.

[y-luis-rojo]

Thanks @y-luis-rojo for the contribution. Seems like a useful capability to add. Added inline comments as well as overall comments to address:

1. Looks like the happy path in unit tests need actual assertions.
2. Please add an AliasServiceIntegrationTest that uses Testcontainers to test adding, updating, removing aliases on a new or existing collection.
3. Please update the docs with this new tool.

Thanks for the comments. I think all are now addressed.

[adityamparikh]

An end to end integration tests AliasServiceIntegrationTest which uses testcontainers still needs to be added.

[y-luis-rojo]

An end to end integration tests AliasServiceIntegrationTest which uses testcontainers still needs to be added.

Sorry, missed to add it. Done.

[adityamparikh]

@epugh Looks good to me. Can you please merge?

[epugh]

@epugh Looks good to me. Can you please merge?

thanks for the review! Still on vacation, but hoping to get some coding time this week.

[epugh]

@y-luis-rojo looks like some lint checks failed...

[adityamparikh]

I approved. @epugh Could we merge?

[adityamparikh]

@epugh re "looks like some lint checks failed" — I dug into this, and the three red jobs are inherited from the branch point, not caused by this PR.

The split is the tell: Build, Unit Tests and Integration Tests all pass; only nativeTest and the two native Docker image jobs fail. This branch points at 582490b, which predates two native-only fixes that have since landed on main:

Fix	Commit	What it repairs
#172	2809af2	DefaultMetaProvider reflection hint — without it every Spring context refresh fails in native image with "Required no-arg constructor not found"
#173	9e71cb4	Docker image tag suffix used by the native integration tests

main measures green natively since those landed, so this is a stale-base problem rather than anything wrong with alias management.

I opened y-luis-rojo/solr-mcp#2 against feature/alias-management to merge current main in. It is merge-only — no changes to @y-luis-rojo's code. Merging it should turn all three jobs green and make this PR mergeable.

Two things I verified specifically, because a clean merge is exactly what hides them:

1. The AliasResult native hint survived the merge. main has been editing that same list (docs: drop stale FieldStats from the native-hints list #180 dropped FieldStats), so the registration sits between upstream changes on both sides. It is still registered — had it been dropped, the alias tools would have serialized to empty JSON in native image only, which is about the worst failure mode to debug.
2. main gained SolrNativeHintsTest, a JVM-path test pinning those registrations. It passes against this branch.

Locally on JDK 25 the merged result is clean for compileJava, compileTestJava and spotlessCheck.

My approval from earlier still stands on the code itself — this is purely about getting CI honest.

[adityamparikh]

Reviewed this as part of a sweep over the open PRs. The alias tools look well-built — blank-input
validation, AliasResult registered in SolrNativeHints, a Testcontainers integration test, and
MCP hints that match what each tool does (readOnlyHint on list, destructiveHint on delete).
Those are easy things to miss and they're all here.

First: the three red native checks are almost certainly not your code. I fetched the branch to
check rather than guess — it forked from 582490b (2026-06-19) and contains neither 2809af2 nor
9e71cb4, the two native-image fixes that landed on main on 2026-08-18. Native was broken on
main for everyone before those. A rebase onto current main should clear them, and is worth
doing before anyone reads those failures as a problem with alias management.

Two suggestions, both small:

AliasResult uses java.util.Date. The other tool responses use Instant —
CollectionCreationResult and SolrHealthStatus both do. Switching would also let you drop the
@JsonFormat pattern, since Instant already serialises as ISO-8601.

createAlias takes collections as a comma-separated String. That maps directly onto
SolrJ's signature, which is presumably why it's shaped that way — but the caller here is an LLM,
and a List<String> removes the "does whitespace after the comma matter?" question entirely.
Joining with , before handing off to CollectionAdminRequest.createAlias keeps the SolrJ call
unchanged. This also matches the direction #164 is taking with typed sort clauses.

Neither is blocking. The rebase is the thing worth doing first.