Show a note when no READY registry or query service is available, instead of scattered "API call failed."

[tkuhn]

When no query service passes nanopub-java's health check, every query-driven part of the page fails on its own, each showing a bare API call failed. (ApiResultComponent.java:105, RdfResultComponent.java:42), while the underlying cause is a single fact about the instance:

ERROR ApiCache - Failed to update cache for RAqmmNSx.../get-newer-versions-of-np?np=...:
  No healthy Nanopub Query instances available
org.nanopub.extra.services.NotEnoughAPIInstancesException: No healthy Nanopub Query instances available

QueryCall.isReadyStatus admits an instance only when its Nanopub-Query-Status header is READY or LOADING_UPDATES, so a service that is still loading is filtered out before any call is attempted. Nothing in the interface says so: the user sees a page that is partly empty and partly complaining, with no indication that it is the deployment rather than the content.

The same applies to the registry side, where ServerIterator skips instances whose Nanopub-Registry-Status is not ready/updating.

This is not only about restricted deployments (#671, where a freshly started local stack spends its first while in LOADING_INITIAL/coreLoading). A public instance hits it whenever its query service is reloading or unreachable — the shape both the 2026-07-28 query-API pool exhaustion and the 2026-07-13 home-page hang presented to users.

Suggested behaviour: a note in the title bar, in the same slot as the other instance-level markers, distinguishing the two cases, as the user's expectation differs:

• still loading — "The query service is still loading. Lists and status information are incomplete." Expected and self-healing; the user should wait rather than investigate.
• nothing reachable — "No query service is currently reachable. Lists and status information are unavailable." An outage.

Two constraints for the implementation:

• Health changes during a session, so unlike the one-off probes in ServiceMode this has to be re-evaluated periodically — a scheduled check on NanodashThreadPool writing a volatile that request threads only read, keeping the probe off the request path (Show outdated view results with a spinner instead of a bare spinner (#599) #600).
• Not knowing must never be worse than the status quo: a failing probe should leave the note hidden rather than assert an outage.