fix top resouces bug

[conorschofield]

When a preference value contains a macro like $(phoebus.install), $(phoebus.user), or $(user.home), the PropertyPreferenceLoader applies .replace("\\", "/").replace(" ", "%20") to make the resolved path URI-safe. However, these replacements were chained on the entire preference value rather than scoped to just the resolved path string.

This caused two issues for multi-part preference values like top_resources:

1. Display names corrupted — spaces in names like "Ops Launcher" became "Ops%20Launcher"
2. Entries silently dropped — the spaces around | delimiters became %20, prepending %20 to URI schemes (e.g., %20pv://, %20https://), causing new URI(...) to throw URISyntaxException and silently skip those entries

For example, a top_resources value with 11 entries would only display 4, with mangled names.

Fix: Move the closing parenthesis so .replace("\\", "/").replace(" ", "%20") applies to the resolved path string (Locations.install().toString()) rather than the full value.replace(...) result.

Checklist

• Testing:

  • The feature has automated tests
  • Tests were run
  • PropertyPreferenceLoaderTest added with 8 test cases covering all three macros, multi-value preferences, Windows paths, and edge cases. Tests verified to pass on fixed code and fail on buggy code.

• Documentation:

  • The documentation is up to date
  • Release notes:
    • Added an entry if the change is breaking or significant

[sonarqubecloud]

Quality Gate passed

Issues
11 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[shroffk]

argh!!! I think ISIS had a similar issue which we fixed in the past.
I am just going to try to find that to ensure we are not messing that up .