Audit medium-risk pages for direct singleton fields (#456 follow-up)

[tkuhn]

Follow-up to #456 (merged in PR #457).

#456 converted four pages (SpacePage, MaintainedResourcePage, ExplorePage, HomePage) from holding direct Space / MaintainedResource references to using String id + IModel<...> LDMs. The same anti-pattern likely exists in the medium-risk pages flagged in #456:

• ResourcePartPage
• UserPage
• SearchPage
• ChannelPage
• ListPage
• PreviewPage
• ViewPage
• SpaceListPage
• DownloadRdfPage

Most hold data that is effectively immutable within a session, so they may not show user-visible staleness — but architecturally they're the same problem and would drift if their underlying data ever changes mid-session.

Pattern to apply

For each page, replace private final Space space (or MaintainedResource, User, etc.) with:

private final String resourceId;
private final IModel<Space> resourceModel = new LoadableDetachableModel<>() {
    @Override protected Space load() {
        return SpaceRepository.get().findById(resourceId);
    }
};

@Override
protected void onDetach() {
    resourceModel.detach();
    super.onDetach();
}

Route inner-class captures (AjaxLazyLoadPanel, ItemListPanel suppliers, etc.) through resourceModel.getObject() instead of the local field.

Tests

Add reflection-based field-architecture tests modeled on SpacePageTest / MaintainedResourcePageTest (added in PR #457) — they assert no direct Space / MaintainedResource instance field, plus presence of the expected id + IModel fields.

Priority

Low. Do only if F5 testing surfaces stale data on any of these pages, or as a tidiness pass when touching them for another reason.