NANODASH_MAIN_REGISTRY / NANODASH_MAIN_QUERY are silently discarded when the URL is not in the library instance list

[tkuhn]

Utils.resolveMainUrl (src/main/java/com/knowledgepixels/nanodash/Utils.java:1505) validates a configured main URL against the instance list that nanopub-java discovers, and falls back to the first library instance when it does not appear there:

if (containsNormalized(instances, envValue)) { ... return envValue; }
if (instances.isEmpty()) { ... return envValue; }   // unvalidated
logger.warn("{}={} is not in the library instance list {}; falling back to first library instance", ...);
return ensureTrailingSlash(instances.get(0));

So pointing an instance at a private registry or query service with NANODASH_MAIN_REGISTRY / NANODASH_MAIN_QUERY alone has no effect: the URL is dropped and a public instance is used instead, with only a warning in the log. The setting only takes effect if NANOPUB_REGISTRY_INSTANCES / NANOPUB_QUERY_INSTANCES are set as well, so that the private URL is in the library list — which is undocumented, and the wrong way round: an operator who explicitly names a service should not have that overruled by a discovered list.

This is the same shape of bug as Nanopublication/nanopub-java#145, where a cached registry list silently won over an explicitly configured one, and it was fixed there by letting the explicit configuration win.

Suggested behaviour: an explicitly configured NANODASH_MAIN_* URL wins, with the instance-list check downgraded to an informational log line rather than an override. The validation still has a point for catching typos, so keeping the warning is useful — just not the substitution.

Worth noting how little these two variables currently reach: their only consumers are QueryPage.java:196, ExplorePage.java:305/:318 and UserData.java:117, i.e. link building and the account list. Actual query dispatch goes through nanopub-java's QueryCall and nanopub retrieval through GetNanopub/ServerIterator, both of which read their own instance lists. Connecting nanodash to a restricted deployment (#671) therefore means setting the library variables too, and the documentation should say so.