Twelve pages hardcode the ReleaseNotes space prefix instead of resolving the top-level space at runtime

Problem

The application is designed to be copyable/renameable to another top-level space: each page resolves its own space at runtime with

#set ($topSpace = $doc.documentReference.extractFirstReference('SPACE').getName())

Twelve places do not follow it and write the literal ReleaseNotes. prefix instead.

include targets: WebHome; Data/WebHome (three includes); Code/HomeReleaseNotes; Code/HomeReleaseChanges; Code/Change/ReleaseNotesChangesMacro; Code/Change/ChangeDisplayerSimple, ChangeDisplayerList, ChangeDisplayerFlow, ChangeDisplayerGrid; Code/Change/ChangeSheet.

Live Data suggest URLs (inside XWiki.JavaScriptExtension objects with parse=1): Code/HomeReleaseNotes (2 sites, classname=ReleaseNotes.Code.ReleaseNoteClass) and Code/HomeCustomReport (5 sites, classname=ReleaseNotes.Code.EntryClass / ...Change.ChangeClass).

Data/WebHome computes $topSpace and then hardcodes the prefix eleven lines later.

Consequence

A copy of the application installed under another top-level space renders against the original space's helper pages and breaks outright once the original is uninstalled. The seven suggest URLs silently stop suggesting anything, because the classname names a class that does not exist in the copy and the suggest endpoint returns an empty list rather than an error.

Notes

Both shapes are fixable. Code/Change/DisplayChangesMacro already proves an include reference can be interpolated when it sits inside a velocity block:

{{include reference="${topSpace}.Code.Change.ChangeDisplayer${stringtool.capitalize($displayer)}"/}}

and the JSX objects are parse=1, so they only need their own #set ($topSpace = ...).

Also worth deciding as part of this: GetChangesMacro and DisplayChangesMacro derive $topSpace from $xcontext.macro.doc while the other 16 pages derive it from $doc. These coincide in a single installation and diverge otherwise; which one is canonical is currently unstated.