Scaled Geometry Collections result in a potential memory leak in Physics/ChaosUpdate

Scaled Geometry Collections (GC) result in a potential memory leak in Physics. Tracing the memory allocation of a single run of the Editor and multiple Play-In-Editor sessions of a scene that contains a scaled GC displays an increase of memory allocation after each session. I've checked all Physics traces and narrowed down the increment to Physics/ChaosUpdate. If the GC has scale (1,1,1) the behavior is not displayed. It's required that the GC is scaled. Breakage of the GC is not required.
I've inspected the code and there are 4 places where LLM_SCOPE(ELLMTag::ChaosUpdate); is called:
PBDRigidsSolver.cpp (line 454)
PhysicsSolverBase.cpp (line 102)
PhysicsSolverBase.cpp (line 122)
PhysicsSolverBase.cpp (line 159)

PhysicsSolverBase.cpp (line 122) is called when exiting a PIE session and might relate to the issue. I've attached it's Callstack to the report.

In a scene that only contains a GC fractured with Uniform and default configurations, I've got a memory allocation LLM Physics/ChaosUpdate during Editor time (valleys):
#PIE sessions|Memory
0|26.60KiB
1|45.29KiB
2|72.00KiB
3|82.66KiB
4|117.40KiB
5|120.04KiB

I won't attach the Trace because it's too big, it exceeds the size limits.

Ticket was generated from 3rd party UDN Vendor report via Slack-bot and is pending pre-processing.

Start editor with -trace=memory,metadata,assetmetadata arguments to enable memory analysis on Unreal Insights
In a empty project, create a basic scene
Create a cube
With the cube selected, enter Fracture Mode (SHIFT+6)
Create a new GeometryCollection (GC) and save
Fracture it using the default Uniform options
Note: The more pieces/instances are placed in the scene, the larger the memory pool will be, making the increase proportionally bigger, so the issue will be made easier to spot, but even a single GC with a few fragments will show the behavior. Breakage of the GC is not necessary.
Start tracing during Editor time and start and stop PIE multiple times to save both Editor memory and PIE memory usage
Stop capture and open up the Trace file
Note the Physics memory usage for each PIE session and more specifically the Physics/ChaosUpdate memory. Since the memory allocation during Editor time is stable it's best to compare the valleys of the Memory Graph and notice that Editor memory is constant between play sessions.
Now change the scale of the geometry collection (or all of them if duplicates were made) to be non 1 (can be more/lesser than 1 and uniform/non-uniform).
Start tracing again and start and stop PIE multiple times.
Open the new trace and note how, after each PIE session, the Editor memory allocation for Physics (and more specifically Physics/ChaosUpdate) grows.

Expected behavior: Memory allocation should remain unchanged regardless the number of PIE sessions that are ran in the Editor and also independent of the scale applied to each GC
Actual behavior: Memory allocation keeps increasing after each PIE session, what indicates a memory leak.

> UnrealEditor-Chaos.dll!Chaos::FPhysicsSolverFrozenGTPreSimCallbacks::GTPreSimCallbacks() Line 122 C++
[Inline Frame] UnrealEditor-Chaos.dll!Chaos::FAllSolverTasks::AdvanceSolver() Line 573 C++
UnrealEditor-Chaos.dll!Chaos::FPhysicsSolverBase::AdvanceAndDispatch_External(double InDt) Line 518 C++
UnrealEditor-Chaos.dll!Chaos::FPhysicsSolverBase::DestroySolver(Chaos::FPhysicsSolverBase & InSolver) Line 337 C++
UnrealEditor-Chaos.dll!FChaosSolversModule::DestroySolver(Chaos::FPhysicsSolverBase * InSolver) Line 269 C++
UnrealEditor-PhysicsCore.dll!FChaosScene::~FChaosScene() Line 117 C++
[External Code]
[Inline Frame] UnrealEditor-Engine.dll!UWorld::ReleasePhysicsScene() Line 1297 C++
UnrealEditor-Engine.dll!UWorld::FinishDestroy() Line 1333 C++
UnrealEditor-CoreUObject.dll!UObject::ConditionalFinishDestroy() Line 1247 C++
UnrealEditor-CoreUObject.dll!IncrementalDestroyGarbage(bool bUseTimeLimit, double TimeLimit) Line 4646 C++
UnrealEditor-CoreUObject.dll!IncrementalPurgeGarbage(bool bUseTimeLimit, double TimeLimit) Line 4525 C++
UnrealEditor-CoreUObject.dll!UE::GC::PostCollectGarbageImpl<1>(EObjectFlags KeepFlags) Line 5557 C++
UnrealEditor-CoreUObject.dll!UE::GC::FReachabilityAnalysisState::PerformReachabilityAnalysisAndConditionallyPurgeGarbage(bool bReachabilityUsingTimeLimit) Line 5746 C++
[Inline Frame] UnrealEditor-CoreUObject.dll!UE::GC::CollectGarbageInternal(EObjectFlags) Line 5302 C++
UnrealEditor-CoreUObject.dll!CollectGarbage(EObjectFlags KeepFlags, bool bPerformFullPurge) Line 5986 C++
UnrealEditor-UnrealEd.dll!UEditorEngine::EndPlayMap() Line 479 C++
UnrealEditor-UnrealEd.dll!UEditorEngine::Tick(float DeltaSeconds, bool bIdleMode) Line 2473 C++
UnrealEditor-UnrealEd.dll!UUnrealEdEngine::Tick(float DeltaSeconds, bool bIdleMode) Line 550 C++
UnrealEditor.exe!FEngineLoop::Tick() Line 5877 C++
[Inline Frame] UnrealEditor.exe!EngineTick() Line 69 C++
UnrealEditor.exe!GuardedMain(const wchar_t * CmdLine) Line 188 C++
UnrealEditor.exe!GuardedMainWrapper(const wchar_t * CmdLine) Line 123 C++
UnrealEditor.exe!LaunchWindowsStartup(HINSTANCE__ * hInInstance, HINSTANCE__ * hPrevInstance, char * __formal, int nCmdShow, const wchar_t * CmdLine) Line 277 C++
UnrealEditor.exe!WinMain(HINSTANCE__ * hInInstance, HINSTANCE__ * hPrevInstance, char * pCmdLine, int nCmdShow) Line 317 C++
[External Code]