Flaky: profiler heap-dump test races the target's first allocations

What

e2e_modules::profiler_dump_analysis_full_stack::test_profiler_object_graph_roots_inspect_and_diff_full_stack failed once on CI with:

panicked at src/sharplsp/tests/e2e_modules/profiler_dump_analysis_full_stack.rs:117:
baseline heap dump must contain StringBuilder instances (ProfileTarget allocates them constantly)

Why

start_profiler_session() starts ProfileTarget, connects the LSP client, and returns immediately — it does not wait for the target to reach its allocation loop. The test then takes the baseline heap dump straight away. If the dump lands before the loop's first iteration, there are no System.Text.StringBuilder instances on the heap and harvest_heap_address returns None.

The comment "ProfileTarget allocates them constantly" is true in steady state but not in the first moments after process start.

Fix

Retry the baseline dump a bounded number of times until the hotspot type is present, rather than assuming it already is. The assertion stays exactly as strong — if the type never appears, the test still fails with the same message — but the start-up race goes away.

Notes

Pre-existing; the test is unmodified on the cleanup branch and had passed on earlier runs of the same branch. Not filed as part of that PR to keep its scope to the restructure and the regressions it exposed.

Start with src/sharplsp/tests/e2e_modules/profiler_dump_analysis_full_stack.rs, especially test_profiler_object_graph_roots_inspect_and_diff_full_stack and start_profiler_session(). Run this test to reproduce or observe the startup race. Done means the baseline dump tolerates startup timing with bounded retries while retaining the existing failure assertion when StringBuilder instances never appear.