fix: NetworkTracker wrongly finishes suspended task as aborted

[philipphofmann]

Description

The NetworkTracker treats NSURLSessionTaskStateSuspended as a terminal state and finishes the corresponding span with a status like “aborted”. This is misleading for NSURLSessionTask–based auto-instrumentation.

In NSURLSession, a suspended task:

• is not cancelled or failed
• can be resumed later and continue the same logical HTTP operation
• may be suspended implicitly by the system (e.g. app backgrounding), which is not an error from the app’s perspective

By finishing the span on suspension, we effectively report an in-flight request as aborted, even though it may later resume and complete successfully.

Current behavior

• When a task transitions to NSURLSessionTaskState.suspended, the SDK finishes the span and sets its status to something equivalent to “aborted”.
• When a task is explicitly cancelled, the SDK finishes the span with a “cancelled” status (which is correct).

https://github.com/getsentry/sentry-cocoa/blob/f0d57aea65cc61752dffa3c68d13acae1baaedd6/Sources/Sentry/SentryNetworkTracker.m#L480-L495

Why this is a problem

• Suspended tasks are not logically finished operations.
• Spans for requests that are temporarily paused (or auto-suspended by the OS) are reported as aborted, which gives a false impression of network failures.
• This also makes it harder to reason about real cancellation vs. temporary suspension in performance data.

Expected / Open question

Suspension should not be treated as an aborted request. Instead, we should treat it as a non-terminal state and come up with a more accurate span handling strategy for NSURLSessionTaskState.suspended (and its transitions back to running, cancellation, or completion).

[linear[bot]]

COCOA-979