SOLR-15752: Migrate admin UI to v2 apis

[epugh]

https://issues.apache.org/jira/browse/SOLR-15752

Description

Start using V2 apis in our solr admin. We need to use them "in anger" if we want to build confidence in them, and to help us move away from v1 equivalents.

Solution

Work with Claude to do the updates to our javascript from v1 to v2. We don't have tests, so this is all manually tested.

I've chosen the easiest apis first.

Tests

Sigh. No JS tests. And not ready to even begin that!

[epugh]

Created https://issues.apache.org/jira/browse/SOLR-18318 to track blocker to finishing this.

[epugh]

Migrated to V2

Controller	What moved	Notes
cores.js	list/add/unload/rename/swap/reload → CoresV2	Full migration
segments.js	get → plain $resource on /api/cores/:core/segments	No generated client existed; response shape identical to v1
threads.js	get → plain $resource on /api/node/threads	No generated client (pre-dates OpenAPI v2 framework); same handler as v1 under the hood
index.js	system info → SystemV2	Full migration
app.js (MainController)	system info fetch in resetMenu(), core-list fetch → SystemV2, CoresV2	Drives nav/sidebar across the whole app
security.js	system info → SystemV2	Ported the 401/403 detection logic to the new callback shape
logging.js	events, levels → LoggingV2	setLevel stayed on v1 (see below)
collections.js	aliases, create/delete alias, create/delete collection, delete shard, create/delete replica, configsets, live-nodes → AliasesV2/ShardsV2/ReplicasV2/ConfigSetsV2/ClusterV2; reloadCollection was already on CollectionsV2 before this work started	Collections.status (CLUSTERSTATUS) stayed on v1 (see below)

Still on v1 — deliberately, with a documented reason

Where	Why
logging.js setLevel	v1's nodes=all broadcasts the log-level change to every node in the cluster; the v2 NodeLoggingApis endpoint is single-node only until SOLR-16738 wires up proxying for it
cloud.js System.get({nodes:...}) (Nodes page)	Found a real bug: v2's multi-node proxying for system info throws a server-side NullPointerException (GetNodeSystemInfo.remoteNodeData never initialized) — filed as a standalone JIRA issue with a suggested one-line fix
collections.js Collections.status (CLUSTERSTATUS)	No v2 endpoint returns the full collections+shards+replicas topology in one call; only per-collection status exists, which would mean N+1 requests. Your call was to leave this on v1
plugins.js	Was migrated to MetricsV2, then you asked me to back it out — fully reverted to v1 Metrics.raw
cloud.js (everything else)	Metrics.get, Zookeeper.* (tree/simple/clusterState/detail) untouched — not in scope of any request so far