fix(cold start): serve pages when a service cannot answer

[tkuhn]

Closes #684.

The failure

Reproduced on master with an empty API cache and a query service the library does not admit: the home page hung, /publish answered 500, and the log carried 37 unhandled exceptions — the chain from the issue, UserData.<init> ← NanodashSession.loadProfileInfo ← page construction, with the error page needing a session of its own and failing the same way.

Behind it was a second one the issue does not name: with the session fixed, HomePage still 500s in MaintainedResourceRepository.findById → ApiCache.retrieveResponseSync. Both repositories already treated a missing response as "nothing yet" but a failing one as fatal.

The fix

• UserData builds from whatever answered and carries isComplete(). Nothing in it is fatal any more except an unreadable local setting file — a misconfiguration, not an outage.
• User.install / shouldReplace never let incomplete data replace complete data (a passing outage must not empty out good data); retryIfIncomplete reloads in the background, at most every 30s, never on a request thread (PR Show outdated view results with a spinner instead of a bare spinner (#599) #600's rule).
• NanodashSession construction cannot fail on profile loading; refreshProfileInfoIfIncomplete(), called from the NanodashPage constructor, reloads the profile once the user data is whole again.
• ApiCache.retrieveResponseIfAvailable — null instead of throw, for the callers holding state whole pages are built from (SpaceRepository, MaintainedResourceRepository). retrieveResponseSync still throws, so a single view keeps reporting its own failure.
• ErrorPage renders without its title bar rather than not at all.
• JustPublishedMessagePanel: the missing-introduction and pending-approval notices are held back while the user data is incomplete — a degraded page must not tell users something false about their own account.

Verification

A second jetty on :37374 against a stub query service answering 503 + Nanopub-Query-Status: LOADING_INITIAL, with NANODASH_API_CACHE_FILE=none — the issue's fresh-deployment scenario — then the stub switched to forwarding to the real service:

	master	with fix
/	hang / 500	200, showing "The query service is still loading. Lists and status information are incomplete."
/publish, /profile, /error	500	200
after the service came up	—	full home page (templates, events, all view sections), no restart

Recovery was watched end to end in the browser: degraded page → service becomes ready → the instance serves its full home page again.

Tests: 1299 pass (8 new — UserDataResilienceTest, two in ApiCacheTest, one in ErrorPageTest). The error-page test was checked against unfixed code: it fails there with the issue's own "Can't instantiate page" error.

Two notes for the reviewer

1. Recovery follows the library's clock, not ours. nanopub-java evicts an unhealthy query instance for NANOPUB_QUERY_EVICTION_COOLDOWN_SECONDS (default 300), so the 30-second retry can only succeed once that lapses. It does recover unattended — just up to five minutes after the service is ready.
2. ServiceHealth.checkQuery can report HEALTHY while dispatch still fails. QueryCall.getApiInstances() returned non-empty the moment the cooldown lapsed while actual calls still threw NotEnoughAPIInstancesException, so the Show a note when no READY registry or query service is available, instead of scattered "API call failed." #681 note can clear before queries work. Left alone here — that is the note's own logic and deserves its own decision.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LqfrG3VXH5tzWXPvYJzXML