refactor: adopt toolregistry-server 0.4.0 App/ServerIdentity pattern

[Oaklight]

Summary

Replaces internal toolregistry-server 0.3.x API usage with the public App/ServerIdentity pattern from 0.4.0.

• New app.py: UXarrayApp(App) subclass with UXARRAY_IDENTITY (ServerIdentity) and prepare_registry() — single entry point for building the tool surface
• Rewritten server.py: delegates to UXarrayApp instead of manually wiring RouteTable → create_mcp_server → asyncio.run(run_stdio/sse/http)
• Bumped toolregistry-server>=0.4.0: old import paths (toolregistry_server.mcp) no longer exist in 0.4.0

No changes to registry.py, cli.py, or any tool functions. Backward-compatible: make_registry(), make_mcp_server(), and server.run() still work.

This aligns with how toolregistry-hub uses the server library.

Test plan

• 312 tests pass (2 pre-existing HEALPix plotting failures unrelated)
• python -m uxarray_mcp still starts stdio server
• ruff clean

[Oaklight]

@rajeeja PR is ready — CI all green (7/7).

This is the 0.4.0 update I mentioned on Slack. Summary of what changed:

Architecture: replaces the internal toolregistry_server.mcp wiring with the public App/ServerIdentity pattern. Server logic consolidated into a single app.py — cleaner foundation for future work (multi-endpoint deployment, auth routing, etc).

New capability: uxarray-mcp openapi CLI subcommand — same tool surface, served as REST/OpenAPI instead of MCP. Useful for non-MCP clients (curl, OpenAI Assistants API, LangChain, etc).

What's untouched: all your domain code (setup, doctor, endpoints, install-claude, tools, remote, registry) — zero changes.

Re: the Argonne deployment discussion — the App class makes multi-instance deployment straightforward. You can run separate uxarray-mcp serve (MCP) and uxarray-mcp openapi (REST) instances behind a reverse proxy, with different profiles if needed (e.g. HPC vs non-HPC).

[Oaklight]

Two proposals for your consideration:

1. CLI structure — align with toolregistry ecosystem

Now that we serve both MCP and OpenAPI, the CLI could mirror the pattern used by toolregistry-hub:

uxarray-mcp mcp [--transport stdio|sse|streamable-http] [--profile core|deferred-full]
uxarray-mcp openapi [--host --port] [--profile core|deferred-full]
uxarray-mcp setup / doctor / endpoints / install-claude  (unchanged)

serve stays as a backward-compat alias for mcp --transport stdio so existing Claude Desktop configs don't break.

2. Project rename: uxarray-mcp → uxarray-server

Since the project now serves both MCP and OpenAPI (REST), the -mcp suffix is too narrow. uxarray-server better reflects what it actually is — same pattern as toolregistry-server.

This would mean:

• PyPI package: uxarray-server
• CLI entry point: uxarray-server mcp / uxarray-server openapi
• Repo: uxarray-server (or keep repo name, just rename the package)
• conda-forge feedstock name update

Not suggesting we do all of this in this PR — just flagging it as a direction worth considering. Happy to help with the rename in a follow-up if you're on board.

[rajeeja]

Merging the refactor — great cleanup.

On the rename: project's too young to lock identity — good on flagging this, will think a bit more along these lines..

[rajeeja]

Approved — clean refactor, all CI green, zero domain-code changes.