fix: release post-publish refreshes on ingest confirmation instead of a blind delay

[tkuhn]

Fixes #629 (the round-trip-confirmation half of #622, left out of #627).

Problem

Publishing set a blind 5-second runAfter delay, after which the background refresh fetched exactly once and dropped the forcedRefresh flag. If the nanopub had not been ingested within those 5 seconds, that one fetch returned the old data, RefreshingResultPanel.poll saw an unchanged digest, and settled — spinner off, stale content left on screen permanently. A too-slow ingest was indistinguishable from "nothing changed".

Change

The wait is now a measurement instead of a guess:

• New published query check-nanopub-loaded — a single indexed lookup on the meta repo (graph npa:graph { ?_np_iri dct:created ?date } limit 1, ~120ms) reporting whether the answering query-service instance has the nanopub. get-latest-version-of-np was deliberately not reused: its pubkey join, (npx:supersedes)* path, and NOT EXISTS make it too expensive for a retry loop. Already published and live.
• QueryApiAccess.isNanopubLoaded(npId) wraps it, uncached.
• ApiCache.clearCache gains a variant taking the just-published nanopub's id (passed through by the publish listener in WicketApplication). The four runAfter wait sites now share one helper, waitOutIngestDelay: poll the probe until the nanopub is confirmed as loaded, then release the refresh after a 1s margin (for trailing repos/instances).

Safety properties

• Hard-bounded: 20s cap, 1s poll interval — a retry storm from many publishing sessions is the load shape that has wedged the query API before, so the bound is strict.
• Deduplicated: concurrent waiters for the same publish (several views on one page) share a single polling loop; results — including negative ones — are cached for 60s so late waiters don't re-poll.
• Fallback preserved: on probe error or timeout, the blind delay applies unchanged; before the query was published, the probe's 400 landed in this branch, so deploy order was free. A broken probe can never make publishing worse than before.
• Request threads never poll: a pending confirmation counts as "waiting for ingest" in retrieveResponseSync, punting to the background as the plain delay already did.

No client-side changes: RefreshPollTimer's 60s deadline already accommodates the longer server-side wait.

Testing

• 3 new unit tests: confirmation releases the refresh long before the fallback delay; a failing probe falls back to the blind delay; a shared negative result short-circuits later waiters. Full suite green (1187 tests).
• Query verified live: 1 row for a loaded nanopub, 0 rows for a missing one.
• Remaining follow-up: watch the first real publish through deployed code to confirm the 1s post-confirmation margin suffices.

🤖 Generated with Claude Code