Fix timing issue for updateSolutionServerProxies calls related to persist ID to UUID refactoring

[Copilot]

This PR addresses timing issues in the ModelUtils.updateSolutionServerProxies() calls that were identified as TODOs following the major persist ID → UUID refactoring in servoy-client (commit e899d29d89a0ec8c9b288550b1137c3163083acc).

Problem

The updateSolutionServerProxies() method was being called too early in the solution deserialization process, specifically in SolutionDeserializer.updateSolution(). At this point:

• Files have been parsed but deleted forms/objects might still be present in the solution
• The solution state is inconsistent - some persists marked for deletion haven't been fully processed
• DataSourceCollectorVisitor could include stale data sources from deleted forms or miss new ones
• This could result in unnecessary server proxies or missing required proxies

The original TODOs highlighted this concern:

// SolutionDeserializer.java:331
// TODO isn't this done too soon? I mean a deleted form from disk for example 
// would not yet be removed from the solution at this point right?

// ServoyModel.java:3023  
// TODO maybe here update used DB severs/tables here instead of sooner? 
// or maybe both now and before...

Solution

Moved the updateSolutionServerProxies() call from the early deserialization phase to after all persist processing is complete:

Removed from: SolutionDeserializer.updateSolution() - called during file parsing
Added to: ServoyModel.handleChangedFiles() - called after all persist updates and strayCats processing

This ensures that:

• All deleted persists (strayCats) have been fully processed
• The solution state is consistent and accurate
• DataSourceCollectorVisitor sees the final, correct set of data sources
• Server proxies are created only for actually needed data sources

Files Changed

• SolutionDeserializer.java: Removed premature call and added explanatory comment
• ServoyModel.java: Added properly timed call with documentation

Impact

This is a timing optimization with no functional changes to the API. The same server proxy functionality is maintained but with better reliability and consistency.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• repo.eclipse.org
  • Triggering command: /usr/lib/jvm/temurin-17-jdk-amd64/bin/java --enable-native-access=ALL-UNNAMED -classpath /usr/share/apache-maven-3.9.11/boot/plexus-classworlds-2.9.0.jar -Dclassworlds.conf=/usr/share/apache-maven-3.9.11/bin/m2.conf -Dmaven.home=/usr/share/apache-maven-3.9.11 -Dlibrary.jansi.path=/usr/share/apache-maven-3.9.11/lib/jansi-native -Dmaven.multiModuleProjectDirectory=/home/REDACTED/work/servoy-eclipse/servoy-eclipse org.codehaus.plexus.classworlds.launcher.Launcher clean compile -q (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.