fix: re-resolve view definitions on a page-level "refresh now"

[tkuhn]

Follow-up to #657 / #662, closing the same gap on the page-level entry.

The problem

"refresh now" in the page title menu forced the structure query and marked the views' results as outdated, but never re-checked the view definitions. Those come from View.latestResolvedViews, a memo re-resolved only once a minute in the background — and that background re-resolution is itself served stale-while-revalidate by QueryApiAccess.latestVersionMap and ApiCache. So a view superseded a moment ago kept rendering as its previous version, and only turned up on the second or third click.

The change

• View.withFreshResolution(Supplier) — inside the scope, the first View.get(id) per id calls refreshLatestVersion(id) instead of reading the memo, and the re-memoized answer serves the rest of the build. buildViewDisplays wraps the whole structure build in it, so it does not matter which id a view is looked up by: a display resolves the version its nanopub references, a built-in view the id hard-coded for it. (A first attempt guessed the id from the query row's ?view; the scope removes the guess.)
• requestViewRefresh() sets the request; the structure update takes it and runs the lookups on the update thread, never on a request thread.
• Views outside the structure (the About and Explore tabs build their own) have no refreshed view list to pick a newer definition up from, so the click re-checks them directly via the new QueryResult.getShownViewId(), the way a view display's own "refresh now" does.
• Publishing re-resolves the definitions too (requestViewDefinitionRefresh(), called from the publish listener): the nanopub just published can be a new version of a view the page shows. Definitions only — refreshing every view's results is what Auto-refresh after publishing doesn't always refresh the right things #622 took away.
• getStructureSignature() includes the resolved view id, not just the referenced one. A new version of an already-referenced view leaves the reference unchanged, so RefreshingStructurePanel would have decided "structure unchanged" and never swapped the content in.

Space-governed views

The case that exposed the gap: SEMANTiCS 2026's extended-message-view (RAbdvJ8… → RAmu7tmj…, "💬 Messages (incl. sub-spaces and resources)" → "💬 All messages") declares gen:governedBy, so it floats by get-latest-governed-version, not the supersedes chain. refreshLatestVersion clears that query's entry as well.

Verified

Headless Playwright against a second jetty on :37374, driving the real menu click:

• SEMANTiCS 2026 space (ref-scoped get-view-displays-unresolved): one click → 1 structure query + 12 forced get-latest-version-of-np + 3 forced get-latest-governed-version lookups, page re-rendering clean;
• home page (pre-resolved get-view-displays): 1 structure query + 1 governed lookup — down from 18 supersedes lookups in the first attempt, since the pre-resolved variant needs no client-side chain lookups;
• no errors in either run.

Not exercised, as in #657: the flip itself on a just-superseded definition, which needs publishing a new view version.