Fix race condition in ProjectCollection.ConfigFileRegistry

[fubhy]

This attempts to tackle a race condition I ran into in CI multiple times whilst working on the last fix.

[Copilot]

Pull request overview

This PR fixes a race condition in the ProjectCollection by ensuring that configFileRegistry and apiOpenedProjects fields are properly cloned before modification. The issue was that these two fields were missing from the clone() method and were being directly modified in Finalize() without ensuring a proper clone, which could lead to concurrent access issues when the old ProjectCollection is still being read while a new one is being built.

Changes:

• Added conditional cloning logic in Finalize() for configFileRegistry and apiOpenedProjects fields
• Updated the clone() method to include the previously missing configFileRegistry and apiOpenedProjects fields

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
internal/project/projectcollectionbuilder.go	Added conditional cloning checks before modifying configFileRegistry and apiOpenedProjects to prevent race conditions
internal/project/projectcollection.go	Added missing configFileRegistry and apiOpenedProjects fields to the clone() method to ensure proper shallow copying

[fubhy]

There seem to be more, unrelated race conditions e.g. https://github.com/microsoft/typescript-go/actions/runs/20938617746/job/60167089124 that the previous CI run ran into. That one appears to be a problem with the scope of the mutex in flushChanges.

[fubhy]

There seem to be more, unrelated race conditions e.g. https://github.com/microsoft/typescript-go/actions/runs/20938617746/job/60167089124 that the previous CI run ran into. That one appears to be a problem with the scope of the mutex in flushChanges.

Attempting to fix that here: #2495