fix(profiling): release the EventPipe session when the SDK shuts down - #5470

SamplingTransactionProfilerFactory.Dispose() disposed the antecedent Task<SampleProfilerSession> rather than the session it wraps, so the EventPipeSession was never released.

That line turned out to be the last of three independent defects sitting between "SDK shuts down" and "EventPipe session released" — fixing it alone would not have changed anything observable.

What was broken

1. SampleProfilerSession.Stop() skipped its own disposals on the happy path. _processing was built with TaskContinuationOptions.OnlyOnFaulted. When eventSource.Process() returns normally the continuation criteria aren't met, so the continuation transitions to Canceled and _processing.Wait() throws AggregateException(TaskCanceledException). EventPipeSession.Dispose() and TraceLogEventSource.Dispose() sat after that call and were never reached — the catch logged Error during sampler profiler session shutdown. and swallowed it. This fired on every clean shutdown, not on some edge case.

2. Nothing ever called Dispose() on the factory. ProfilingIntegration wasn't IDisposable, so Hub never added it to _integrationsToCleanup, and the factory's only other reference is options.TransactionProfilerFactory, which nothing disposes. Outside of tests, SamplingTransactionProfilerFactory.Dispose() was unreachable.

3. The reported bug. The ContinueWith parameter is the antecedent task, so Dispose() called Task.Dispose() — a near no-op on a completed task — instead of disposing the session.

What this changes

ProfilingIntegration now owns the factory it creates. It implements IDisposable so the Hub tears it down on shutdown, and disposal also clears options.TransactionProfilerFactory, so a SentryOptions reused for a later hub gets a working profiler rather than a stale reference. It only touches a factory it created itself — one supplied from elsewhere is left alone.

SamplingTransactionProfilerFactory.Dispose() now actually stops the session. StartEventPipeSession() can block for up to 30 seconds and can't be cancelled, so disposal can land before there is any session to stop; a lock hands the session between the startup task and Dispose() so exactly one of the two tears it down. The wait for the first event is cancelled on disposal rather than left to block indefinitely. Both waits are bounded at 2 seconds so a wedged session can't hang shutdown.

SampleProfilerSession.Stop() moves the disposals into a finally, so the EventPipe connection is released even when stopping the session or draining its events fails.

Impact

Low, and narrower than the issue suggests. The session is created once and lives for the SDK's lifetime — SamplingTransactionProfiler.Stop() only clears _inProgress, it never touches the session — so the only disposal point is SDK shutdown, which is normally process shutdown, where the OS reclaims the handle and the TraceLog regardless. Nothing accumulates while an application runs.

It matters where the process outlives the SDK: repeated Init/Close cycles strand one EventPipeSession plus its TraceLog per cycle, and hosts that close Sentry but keep running never release the pipe.

The issue links this to the Windows Service memory growth in #3375. That link doesn't hold up — a service that initialises Sentry once would never reach any of these paths. The steady-state growth reported in #5469 is a separate mechanism and is not addressed here.

Notes

• Defect 1 has a visible signature in diagnostic logs: Error during sampler profiler session shutdown. on every clean shutdown with profiling enabled. Worth asking anyone reporting profiler-related resource growth whether they see it.
• Hub.Dispose() now does real work for profiling users where it previously did none.
• Most of Sentry.Profiling.Tests is Skip.If(TestEnvironment.IsGitHubActions) because it opens real EventPipe sessions. The ProfilingIntegration tests added here are plain [Fact]s that do run in CI; the two session-level tests follow the existing skip pattern.
• AGENTS.md gains a short section recording the repo's preference for code over comments. Happy to split that into its own PR if it doesn't belong here.

Fixes #5418